企業IT架構轉型中微服務架構實踐中常見問題總結

作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有雲PaaS平臺架構涉及經驗，長期從事一線項目實踐

今天討論下在微服務架構實踐中經常遇到的一些問題的思考，其中有些來源於我們自己的微服務改造項目，有些來源於客戶現場微服務架構實施項目和售前方案溝通。

本文僅針對關鍵問題點進行討論，具體如下：

• 微服務下資料庫劃分
• 微服務開發和技術框架的選擇
• 微服務和DevOps，容器雲集成
• 微服務網關和註冊中心
• 微服務相關關鍵技術，如限流熔斷，安全，服務鏈監控等

對於微服務相關的基礎知識，大家在網上基本都可以搜索到就不再重複敘述，對於SOA和微服務，中臺架構等的區別等，也可以參考我前面發布過的文章。

資料庫拆分是否和微服務必須1對1

在最早談微服務架構的時候我們就談到。要確保每個微服務都獨立自治和鬆耦合，那麼微服務從資料庫到邏輯層到前臺全部都要進行縱向拆分。

即資料庫的拆分是整個微服務架構設計中的一個關鍵內容。

而這裡有一個關鍵思考就是，在微服務實踐中你會看到，實際上你上層的微服務組件的拆分相當來說會更加細，一個不算複雜的業務系統拆分到20到30個微服務組件都是正常情況。

而對於資料庫也拆分為20個獨立的DataBase顯然不合理。

這個一方面是增加了資料庫本身的管理複雜度，同時由於資料庫的太細拆分也引入了更多的分布式事務處理問題，跨庫數據關聯查詢不方便等問題。因此在這裡，最好的建議是我們引入一個業務域的概念，即：

可以按業務域來進行資料庫拆分，每一個業務域相當獨立並對應一個獨立資料庫，但是業務域裡面本身可以有多個上層的微服務模塊組件。同一個業務域裡面的微服務仍然通過註冊中心進行訪問和調用。

即同一個業務域裡面的微服務在邏輯層本身還是解耦的，只能夠通過API接口訪問調用，以方便分布式部署，但是資料庫層本身不拆分，共享同一個資料庫。

比如在我們的項目裡面，我們會將4A和流程引擎兩個微服務共享一個資料庫，將費用報帳，差旅報帳，借款報帳等獨立微服務共享一個報帳資料庫。

在這種方式下雖然沒有實現資料庫的徹底解耦，但是通過在邏輯層的微服務拆分和解耦，我們可以實現微服務部署包的更加細粒度管理。同時當存在業務邏輯變更的時候，我們也僅僅需要變更相應的微服務模塊，做到變更影響最小化目的。

是否使用SpringCloud全家桶

可以看到如果採用SpingCLoud微服務技術開發框架，那麼對應服務註冊中心，限流熔斷，微服務網關，負載均衡，配置中心，安全，聲明式調用所有能力全部提供。

你需要做的就是採用SpringBoot框架來開發一個個微服務組件即可。

當然在我們實施的項目裡面也存在另外一種方式，即只使用SpringBoot框架進行單個微服務組件的開發，其次再去組合和集成當前業界主流的微服務開源技術組件產品。

• 服務註冊中心：阿里的Nacos註冊中心
• 服務配置中心：攜程開源的Apollo配置中心
• 限流熔斷：阿里的Sentinel
• 服務鏈監控：直接對SkyWalking服務鏈監控進行集成
• API網關：採用Kong網關來實現API集成和管控治理

當然你也可能完全不採用SpringBoot，而是走更加高效的支持RPC調用的Dubbo開源框架進行微服務組件的開發和集成。

如果從微服務技術平臺的構建和快速開發上來說，當然是你直接選擇SpingCLoud整個開源框架和組件來實現最簡單，而且基本也完全能夠滿足需求。對於日常傳統企業應用來說，性能完全足夠，也不存在說性能無法滿足的情況。畢竟不是所有項目都類似網際網路存在海量數據訪問和大並發下的高性能要求。

如果採用各種開源組件，技術框架自己集成，那麼肯定是存在前期的基礎技術平臺搭建，集成驗證等相關的工作量。同時本身也會增加整個基礎架構的複雜度。比如你採用了Nacos註冊中心，對於註冊中心你同樣需要去進行集群化配置，以滿足高可用性的需求。

綜合以上描述，簡單總結就是：

• 如果圖省事，沒有太高性能要求，直接採用SpingCloud整體框架
• 如果性能要求高，自己技術儲備足夠，可以自己進行開源技術組件集成

那麼在我們實際的微服務架構實施項目裡面，我們會看到第三個場景。

比如一個集團型企業，本身一個計劃管理系統進行前期架構設計後拆分為10個微服務模塊，需要招標三家軟體開發商來定製開發。對開發商要求也是進行微服務架構化開發。

在這個時候我們就發現一個關鍵問題，各個廠家自己採用微服務架構沒有關係，但是從整個大應用角度我們實際上是存在對10個微服務模塊進行統一的微服務治理和管控需求的。類似API網關，類似服務配置中心等。

而這些組件就不太適合再使用SpingCLoud裡面的技術組件，而是需要從單個微服務架構體系裡面提取出來，形成一個共享的服務能力。在這種時候，我們的建議就是儘量去集成和使用第三方的其它開源技術組件來進行管控治理。

比如上面這個例子，三家供應商可以保留最基礎的配置。

即某家供應商開發A，B，C三個微服務模塊的時候，可以啟用Eureka+Feign+Ribbon來完成自己開發的三個組件的內部集成，API接口註冊和調用。

但是三個供應商之間的模塊要協同的時候則統一使用外部搭建的共享技術服務平臺。

• 比如API接口註冊到統一的Kong網關上，Kong網關由平臺集成商管理
• 比如涉及到三家的一些共性配置由SpingCloud Config統一轉到Apollo配置中心

因此再簡單總結下就是，評估是否採用SpingCLoud全套方案的時候，還需要評估是否存在跨有明確邊界的團隊協同的情況。或者是否存在類似集團型企業，多個業務系統微服務大集成的情況。如果存在，那麼一些共性技術服務能力就必須抽出獨立建設。

開發團隊如何拆分的問題？

我們在實施微服務和雲原生轉型的時候，你看起來好像是IT系統分為了多個微服務，但是更加重要的是業務組織和團隊本身需要分解為微服務，分解高度獨立自治的業務團隊。

每個團隊都配置獨立的前後端開發，需求，測試人員高度自治。

那麼在拆分為多為業務團隊後，如何保證原來一個大應用和產品的概念一致性或架構完整性。在這裡我們提出，對於整體的產品規劃和總體架構設計仍然需要集中化統一進行，然後在拆分和分配到各個微服務開發團隊。

那麼這裡的架構設計包括哪些內容呢？具體如下：

• 各個微服務模塊的功能列表清單
• 各個微服務模塊的接口清單
• 資料庫的拆分和數據表的Owner歸屬

以上三點就是最重要的架構設計需要提前進行的點。這個清楚後即可以分配到各個微服務團隊，那麼微服務團隊高度自治和扁平化，各個團隊之間之間進行協同和溝通，而不需要再通過架構師來協同增加溝通路徑。

即產品規劃和架構師很類似微服務架構裡面的註冊控制中心的職責。這也是我們常說的技術上的微服務拆分，實際上真正先行的業務組織團隊的架構調整和職責拆分。

那麼這個開發團隊如何拆？

首先不可能你拆分了20個微服務，就拆分出20個開發團隊。這裡面仍然有域劃分的概念在裡面，即對20個微服務還要進行歸類，以方面拆分。

• 方式1：按縱向業務域進行歸類，參考我們前面資料庫拆分方法
• 方式2：按橫向分層歸類，比如平臺層團隊，中臺層團隊，前臺和APP應用團隊

在團隊拆分後，我們可以看到每一個開發小組必須配置前端開發，後端開發和測試人員。對於需求可以統一進行配置不拆分到開發組。當然也可以每個開發組配置一個需求細化人員，而僅僅在整個大團隊配置產品經理出產品需求。對產品需求的細化還是到開發組內部完成。

為何如此強調開發團隊要拆？

簡單來說，就是各個開發團隊內部的工作應該是對其它開發團隊透明不可見的。開發團隊之間高度直治，只能夠通過粗粒度的接口交付。

如果開發團隊本身不拆分，你會看到，一個開發團隊管理多個微服務模塊的時候，我們在前面制訂的各種微服務開發規範，規約等很容易就被破壞，而這些事後審計和修改都會花費大量的時間進行變更和返工。

舉個簡單的例子，拆分為2個DataBase庫後，同一個開發人員管理的時候，往往就省事的通過兩個庫間的跨庫關聯查詢來解決問題，而這在微服務開發規約裡面是不允許的。

當然從軟體企業本身的IT治理管控來說，這也是最好的方案，對於一個大項目或大應用系統，並不是每個開發人員都能夠看到所有項目模塊原始碼，其它非自己Owner的組件只能夠消費和使用接口，其它內容都是不可見。

對於服務註冊中心和API網關選擇

對於服務註冊中心和API網關，在前面我有專門文章詳細分析。

什麼時候需要使用API網關？

如果一個微服務架構下，雖然不會外部的其它應用進行交互和集成，但是整個應用本身存在APP應用端，而APP應用端通過前後端分析開發，同時需要通過網際網路訪問。本身存在需要一個統一訪問API訪問入口，同時也需要考慮和內部微服務模塊進一步進行安全隔離。

當我們談到這裡的時候，你會發現我們常說的API網關的服務代理或透傳能力，實際和我們常說的Ngnix反向代理或路由是一個意思。

如果你僅僅是為了統一API接口的訪問出口，並考慮類似DMZ區的安全隔離，那麼在你架構前期完全不需要馬上實施API網關，直接採用Ngnix進行服務路由代理即可。因為在這種架構下，API接口消費端，提供端全部是一個開發團隊開發，各種問題分析排查都相當方便，類似API接口安全訪問等也可以通過JWT，Auth2.0等統一實現，而且這個過程也並不複雜。

能力開放或多應用外部集成對API管控治理需要

但是當我們面臨是和多個外部應用集成，或者說將自己的API接口服務能力開放給外部多個合作夥伴使用的時候，這個時候對於API接口的管控治理要求自然增加。

即在常規的服務代理路由基礎上，需要增加類似負載均衡，安全，日誌，限流熔斷等各種能力，而且我們不希望這些能力在API接口開發的時候考慮，而是希望這些能力是在API接入到網關的時候統一靈活配置來實現管控。

那麼這個時候使用API網關作用就體現出來。

多個開發團隊協同，服務治理標準化需要

這個是我理解的需要API網關的第二個場景，這個有點類似於傳統IT架構下對ESB服務總線的需求。當存在多個開發團隊的時候，我們就需要對各個開發團隊註冊和接入的API接口服務進行統一管理，而這個時候就需要有API網關來實現。

即跨開發團隊的API接口集成交付的統一管控都由API網關來複製，包括安全，日誌審計，流量控制等，這些內容在多團隊協同的時候不可能再依賴單個團隊內部的一些技術，開發規範約定，而是需要有一個統一的標準。

同時多個開發團隊協同和集成，必須有一個統一的集成方來解決協同中的問題。即使是在ServiceMesh服務網格架構下，我們也可以看到有一個控制中心來統一協調。

在使用API網關後技術組件的選擇上

注意，對於API網關本身具備負載均衡，限流熔斷，服務代理的能力。

即在註冊中心下，Eureka+Feign+Ribbon+Hystrix全部可以轉由API網關來完成。但是一個應用的完整微服務架構可能存在一個API接口既要滿足內部組件的API消費調用，又需要將該接口通過API網關暴露給外部應用使用。

通過API網關對外保留Http Rest API接口，傳統API消費訪問而不再是類似Feign聲明式方式進行類似內部API接口方式調用。如下圖：

可以看到，微服務A既需要滿足內部微服務B作為消費方，通過服務註冊中心進行消費調用，也需要滿足外部APP通過API網關接口進行消費調用。

那麼進入到微服務A集群的流量實際上是沒有一個統一的入口的。

在這種場景下如果企業了Hystrix限流熔斷，那麼也僅僅是對內部的微服務模塊組件間的消費調用進行控制。而對於外部APP限流，仍然還需要啟用網關上的限流熔斷功能。

微服務架構和容器雲集成的集群和負載均衡

最後談下微服務架構和Kubernetes+Docker容器雲集成後的服務發現和負載均衡問題。

前面談到在採用Eureka服務註冊中心的時候，對於同一個微服務模塊A，我們可以啟動多個微服務實例，不同的埠號。在埠啟動後通過Eureka來實現服務的自動註冊和發現。然後通過Ribbon來實現服務訪問的負載均衡處理。

也就是說我們添加和部署微服務模塊A節點是手工完成的。

但是在DevOps持續集成下，在實施Kubernetes+Docker容器雲後，我們可以通過k8s來實現微服務節點資源的動態擴展。擴展的Pod資源統一由Kubernetes來實現集群負載均衡均衡，即對外只需要通過Node+埠號訪問即可。

所以在這個時候實際有兩種做法。

做法1：不再使用Eureka服務註冊和發現

在這種時候，不再使用Eureka服務註冊發現，而是通過Kubernates動態部署後的VIP進行訪問，由Kubernates來進行後臺節點的負載均衡。

這個時候我們只能夠按常規調用Http Rest API接口的方式進行接口消費和調用，類似原來的Feign聲明式調用可能不再適合。也就是說在這種場景下你只使用SpringBoot開發獨立的能夠暴露Http Rest API接口的微服務。不再使用SpringCLoud框架中的Eureka+Feign+Ribbon。

做法2：採用Eureka來替代Kubernetes中的Service

在這種場景下，即不使用Kubernetes本身的集群功能，而是將動態部署出來的微服務模塊還是自動化註冊到Eureka服務註冊中心統一管理。也就是還是按傳統的SpringCLoud框架體系來進行架構搭建。

在這種思路下可以進一步保留SpingCLoud下的限流，容錯，心跳監測等方面的關鍵能力。

做法3：進一步的思路還是ServiceMesh

實際上我們看到進一步的思路還是類似Istio的完全去中心化微服務治理方案。在這種模式下可以更好的通過Sidecar來實現相關服務註冊，發現，限流熔斷，安全等各種關鍵服務治理管控能力。

如果微服務模塊全部是通過Kubernetes部署到Docker容器裡面，那麼我們可以看到完全可以在k8s進行鏡像製作和容器部署的時候將SideCar的內容附加到具體的部署包裡面實現集成。

簡單來說，就是：

我們在開發微服務模塊的時候完全不需要考慮太多的分布式API接口集成交互，但是和Kubernetes和Service Mesh集成後就具備了分布式接口調用和集成的能力。同時也具備了對API接口的安全，日誌，限流熔斷的管理能力。

因此也常說，Service Mesh是Kubernetes支撐微服務能力拼圖的最後一塊。

---

歡迎關注@人月聊IT 分享SOA，微服務，DevOps平臺規劃和建設。