有哪些微服務架構設計的問題

這篇文章主要講解了“有哪些微服務架構設計的問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“有哪些微服務架構設計的問題”吧！

數據庫拆分是否和微服務必須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，Auth3.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支撐微服務能力拼圖的最后一塊。

感謝各位的閱讀，以上就是“有哪些微服務架構設計的問題”的內容了，經過本文的學習后，相信大家對有哪些微服務架構設計的問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！