[[343325]]

今天討論下在微服務(wù)架構(gòu)實踐中經(jīng)常遇到的一些問題的思考，其中有些來源于我們自己的微服務(wù)改造項目，有些來源于客戶現(xiàn)場微服務(wù)架構(gòu)實施項目和售前方案溝通。

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

• 微服務(wù)下數(shù)據(jù)庫劃分
• 微服務(wù)開發(fā)和技術(shù)框架的選擇
• 微服務(wù)和DevOps，容器云集成
• 微服務(wù)網(wǎng)關(guān)和注冊中心
• 微服務(wù)相關(guān)關(guān)鍵技術(shù)，如限流熔斷，安全，服務(wù)鏈監(jiān)控等

對于微服務(wù)相關(guān)的基礎(chǔ)知識，大家在網(wǎng)上基本都可以搜索到就不再重復(fù)敘述，對于SOA和微服務(wù)，中臺架構(gòu)等的區(qū)別等，也可以參考我前面發(fā)布過的文章。

數(shù)據(jù)庫拆分是否和微服務(wù)必須1對1

在最早談微服務(wù)架構(gòu)的時候我們就談到。要確保每個微服務(wù)都獨立自治和松耦合，那么微服務(wù)從數(shù)據(jù)庫到邏輯層到前臺全部都要進行縱向拆分。

即數(shù)據(jù)庫的拆分是整個微服務(wù)架構(gòu)設(shè)計中的一個關(guān)鍵內(nèi)容。

而這里有一個關(guān)鍵思考就是，在微服務(wù)實踐中你會看到，實際上你上層的微服務(wù)組件的拆分相當(dāng)來說會更加細(xì)，一個不算復(fù)雜的業(yè)務(wù)系統(tǒng)拆分到20到30個微服務(wù)組件都是正常情況。

而對于數(shù)據(jù)庫也拆分為20個獨立的DataBase顯然不合理。

這個一方面是增加了數(shù)據(jù)庫本身的管理復(fù)雜度，同時由于數(shù)據(jù)庫的太細(xì)拆分也引入了更多的分布式事務(wù)處理問題，跨庫數(shù)據(jù)關(guān)聯(lián)查詢不方便等問題。因此在這里，最好的建議是我們引入一個業(yè)務(wù)域的概念，即：

可以按業(yè)務(wù)域來進行數(shù)據(jù)庫拆分，每一個業(yè)務(wù)域相當(dāng)獨立并對應(yīng)一個獨立數(shù)據(jù)庫，但是業(yè)務(wù)域里面本身可以有多個上層的微服務(wù)模塊組件。同一個業(yè)務(wù)域里面的微服務(wù)仍然通過注冊中心進行訪問和調(diào)用。

即同一個業(yè)務(wù)域里面的微服務(wù)在邏輯層本身還是解耦的，只能夠通過API接口訪問調(diào)用，以方便分布式部署，但是數(shù)據(jù)庫層本身不拆分，共享同一個數(shù)據(jù)庫。

比如在我們的項目里面，我們會將4A和流程引擎兩個微服務(wù)共享一個數(shù)據(jù)庫，將費用報賬，差旅報賬，借款報賬等獨立微服務(wù)共享一個報賬數(shù)據(jù)庫。

在這種方式下雖然沒有實現(xiàn)數(shù)據(jù)庫的徹底解耦，但是通過在邏輯層的微服務(wù)拆分和解耦，我們可以實現(xiàn)微服務(wù)部署包的更加細(xì)粒度管理。同時當(dāng)存在業(yè)務(wù)邏輯變更的時候，我們也僅僅需要變更相應(yīng)的微服務(wù)模塊，做到變更影響最小化目的。

是否使用SpringCloud全家桶

可以看到如果采用SpingCLoud微服務(wù)技術(shù)開發(fā)框架，那么對應(yīng)服務(wù)注冊中心，限流熔斷，微服務(wù)網(wǎng)關(guān)，負(fù)載均衡，配置中心，安全，聲明式調(diào)用所有能力全部提供。

你需要做的就是采用SpringBoot框架來開發(fā)一個個微服務(wù)組件即可。

當(dāng)然在我們實施的項目里面也存在另外一種方式，即只使用SpringBoot框架進行單個微服務(wù)組件的開發(fā)，其次再去組合和集成當(dāng)前業(yè)界主流的微服務(wù)開源技術(shù)組件產(chǎn)品。

• 服務(wù)注冊中心：阿里的Nacos注冊中心
• 服務(wù)配置中心：攜程開源的Apollo配置中心
• 限流熔斷：阿里的Sentinel
• 服務(wù)鏈監(jiān)控：直接對SkyWalking服務(wù)鏈監(jiān)控進行集成
• API網(wǎng)關(guān)：采用Kong網(wǎng)關(guān)來實現(xiàn)API集成和管控治理

當(dāng)然你也可能完全不采用SpringBoot，而是走更加高效的支持RPC調(diào)用的Dubbo開源框架進行微服務(wù)組件的開發(fā)和集成。

如果從微服務(wù)技術(shù)平臺的構(gòu)建和快速開發(fā)上來說，當(dāng)然是你直接選擇SpingCLoud整個開源框架和組件來實現(xiàn)最簡單，而且基本也完全能夠滿足需求。對于日常傳統(tǒng)企業(yè)應(yīng)用來說，性能完全足夠，也不存在說性能無法滿足的情況。畢竟不是所有項目都類似互聯(lián)網(wǎng)存在海量數(shù)據(jù)訪問和大并發(fā)下的高性能要求。

如果采用各種開源組件，技術(shù)框架自己集成，那么肯定是存在前期的基礎(chǔ)技術(shù)平臺搭建，集成驗證等相關(guān)的工作量。同時本身也會增加整個基礎(chǔ)架構(gòu)的復(fù)雜度。比如你采用了Nacos注冊中心，對于注冊中心你同樣需要去進行集群化配置，以滿足高可用性的需求。

綜合以上描述，簡單總結(jié)就是：

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

那么在我們實際的微服務(wù)架構(gòu)實施項目里面，我們會看到第三個場景。

比如一個集團型企業(yè)，本身一個計劃管理系統(tǒng)進行前期架構(gòu)設(shè)計后拆分為10個微服務(wù)模塊，需要招標(biāo)三家軟件開發(fā)商來定制開發(fā)。對開發(fā)商要求也是進行微服務(wù)架構(gòu)化開發(fā)。

在這個時候我們就發(fā)現(xiàn)一個關(guān)鍵問題，各個廠家自己采用微服務(wù)架構(gòu)沒有關(guān)系，但是從整個大應(yīng)用角度我們實際上是存在對10個微服務(wù)模塊進行統(tǒng)一的微服務(wù)治理和管控需求的。類似API網(wǎng)關(guān)，類似服務(wù)配置中心等。

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

比如上面這個例子，三家供應(yīng)商可以保留最基礎(chǔ)的配置。

即某家供應(yīng)商開發(fā)A，B，C三個微服務(wù)模塊的時候，可以啟用Eureka+Feign+Ribbon來完成自己開發(fā)的三個組件的內(nèi)部集成，API接口注冊和調(diào)用。

但是三個供應(yīng)商之間的模塊要協(xié)同的時候則統(tǒng)一使用外部搭建的共享技術(shù)服務(wù)平臺。

• 比如API接口注冊到統(tǒng)一的Kong網(wǎng)關(guān)上，Kong網(wǎng)關(guān)由平臺集成商管理
• 比如涉及到三家的一些共性配置由SpingCloud Config統(tǒng)一轉(zhuǎn)到Apollo配置中心

因此再簡單總結(jié)下就是，評估是否采用SpingCLoud全套方案的時候，還需要評估是否存在跨有明確邊界的團隊協(xié)同的情況?；蛘呤欠翊嬖陬愃萍瘓F型企業(yè)，多個業(yè)務(wù)系統(tǒng)微服務(wù)大集成的情況。如果存在，那么一些共性技術(shù)服務(wù)能力就必須抽出獨立建設(shè)。

開發(fā)團隊如何拆分的問題？

我們在實施微服務(wù)和云原生轉(zhuǎn)型的時候，你看起來好像是IT系統(tǒng)分為了多個微服務(wù)，但是更加重要的是業(yè)務(wù)組織和團隊本身需要分解為微服務(wù)，分解高度獨立自治的業(yè)務(wù)團隊。

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

那么在拆分為多為業(yè)務(wù)團隊后，如何保證原來一個大應(yīng)用和產(chǎn)品的概念一致性或架構(gòu)完整性。在這里我們提出，對于整體的產(chǎn)品規(guī)劃和總體架構(gòu)設(shè)計仍然需要集中化統(tǒng)一進行，然后在拆分和分配到各個微服務(wù)開發(fā)團隊。

那么這里的架構(gòu)設(shè)計包括哪些內(nèi)容呢？具體如下：

• 各個微服務(wù)模塊的功能列表清單
• 各個微服務(wù)模塊的接口清單
• 數(shù)據(jù)庫的拆分和數(shù)據(jù)表的Owner歸屬

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

即產(chǎn)品規(guī)劃和架構(gòu)師很類似微服務(wù)架構(gòu)里面的注冊控制中心的職責(zé)。這也是我們常說的技術(shù)上的微服務(wù)拆分，實際上真正先行的業(yè)務(wù)組織團隊的架構(gòu)調(diào)整和職責(zé)拆分。

那么這個開發(fā)團隊如何拆？

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

• 方式1：按縱向業(yè)務(wù)域進行歸類，參考我們前面數(shù)據(jù)庫拆分方法
• 方式2：按橫向分層歸類，比如平臺層團隊，中臺層團隊，前臺和APP應(yīng)用團隊

在團隊拆分后，我們可以看到每一個開發(fā)小組必須配置前端開發(fā)，后端開發(fā)和測試人員。對于需求可以統(tǒng)一進行配置不拆分到開發(fā)組。當(dāng)然也可以每個開發(fā)組配置一個需求細(xì)化人員，而僅僅在整個大團隊配置產(chǎn)品經(jīng)理出產(chǎn)品需求。對產(chǎn)品需求的細(xì)化還是到開發(fā)組內(nèi)部完成。

為何如此強調(diào)開發(fā)團隊要拆？

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

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

舉個簡單的例子，拆分為2個DataBase庫后，同一個開發(fā)人員管理的時候，往往就省事的通過兩個庫間的跨庫關(guān)聯(lián)查詢來解決問題，而這在微服務(wù)開發(fā)規(guī)約里面是不允許的。

當(dāng)然從軟件企業(yè)本身的IT治理管控來說，這也是最好的方案，對于一個大項目或大應(yīng)用系統(tǒng)，并不是每個開發(fā)人員都能夠看到所有項目模塊源代碼，其它非自己Owner的組件只能夠消費和使用接口，其它內(nèi)容都是不可見。

對于服務(wù)注冊中心和API網(wǎng)關(guān)選擇

對于服務(wù)注冊中心和API網(wǎng)關(guān)，在前面我有專門文章詳細(xì)分析。

什么時候需要使用API網(wǎng)關(guān)？

如果一個微服務(wù)架構(gòu)下，雖然不會外部的其它應(yīng)用進行交互和集成，但是整個應(yīng)用本身存在APP應(yīng)用端，而APP應(yīng)用端通過前后端分析開發(fā)，同時需要通過互聯(lián)網(wǎng)訪問。本身存在需要一個統(tǒng)一訪問API訪問入口，同時也需要考慮和內(nèi)部微服務(wù)模塊進一步進行安全隔離。

當(dāng)我們談到這里的時候，你會發(fā)現(xiàn)我們常說的API網(wǎng)關(guān)的服務(wù)代理或透傳能力，實際和我們常說的Ngnix反向代理或路由是一個意思。

如果你僅僅是為了統(tǒng)一API接口的訪問出口，并考慮類似DMZ區(qū)的安全隔離，那么在你架構(gòu)前期完全不需要馬上實施API網(wǎng)關(guān)，直接采用Ngnix進行服務(wù)路由代理即可。因為在這種架構(gòu)下，API接口消費端，提供端全部是一個開發(fā)團隊開發(fā)，各種問題分析排查都相當(dāng)方便，類似API接口安全訪問等也可以通過JWT，Auth2.0等統(tǒng)一實現(xiàn)，而且這個過程也并不復(fù)雜。

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

但是當(dāng)我們面臨是和多個外部應(yīng)用集成，或者說將自己的API接口服務(wù)能力開放給外部多個合作伙伴使用的時候，這個時候?qū)τ贏PI接口的管控治理要求自然增加。

即在常規(guī)的服務(wù)代理路由基礎(chǔ)上，需要增加類似負(fù)載均衡，安全，日志，限流熔斷等各種能力，而且我們不希望這些能力在API接口開發(fā)的時候考慮，而是希望這些能力是在API接入到網(wǎng)關(guān)的時候統(tǒng)一靈活配置來實現(xiàn)管控。

那么這個時候使用API網(wǎng)關(guān)作用就體現(xiàn)出來。

多個開發(fā)團隊協(xié)同，服務(wù)治理標(biāo)準(zhǔn)化需要

這個是我理解的需要API網(wǎng)關(guān)的第二個場景，這個有點類似于傳統(tǒng)IT架構(gòu)下對ESB服務(wù)總線的需求。當(dāng)存在多個開發(fā)團隊的時候，我們就需要對各個開發(fā)團隊注冊和接入的API接口服務(wù)進行統(tǒng)一管理，而這個時候就需要有API網(wǎng)關(guān)來實現(xiàn)。

即跨開發(fā)團隊的API接口集成交付的統(tǒng)一管控都由API網(wǎng)關(guān)來復(fù)制，包括安全，日志審計，流量控制等，這些內(nèi)容在多團隊協(xié)同的時候不可能再依賴單個團隊內(nèi)部的一些技術(shù)，開發(fā)規(guī)范約定，而是需要有一個統(tǒng)一的標(biāo)準(zhǔn)。

同時多個開發(fā)團隊協(xié)同和集成，必須有一個統(tǒng)一的集成方來解決協(xié)同中的問題。即使是在ServiceMesh服務(wù)網(wǎng)格架構(gòu)下，我們也可以看到有一個控制中心來統(tǒng)一協(xié)調(diào)。

在使用API網(wǎng)關(guān)后技術(shù)組件的選擇上

注意，對于API網(wǎng)關(guān)本身具備負(fù)載均衡，限流熔斷，服務(wù)代理的能力。

即在注冊中心下，Eureka+Feign+Ribbon+Hystrix全部可以轉(zhuǎn)由API網(wǎng)關(guān)來完成。但是一個應(yīng)用的完整微服務(wù)架構(gòu)可能存在一個API接口既要滿足內(nèi)部組件的API消費調(diào)用，又需要將該接口通過API網(wǎng)關(guān)暴露給外部應(yīng)用使用。

通過API網(wǎng)關(guān)對外保留Http Rest API接口，傳統(tǒng)API消費訪問而不再是類似Feign聲明式方式進行類似內(nèi)部API接口方式調(diào)用。如下圖：

可以看到，微服務(wù)A既需要滿足內(nèi)部微服務(wù)B作為消費方，通過服務(wù)注冊中心進行消費調(diào)用，也需要滿足外部APP通過API網(wǎng)關(guān)接口進行消費調(diào)用。

那么進入到微服務(wù)A集群的流量實際上是沒有一個統(tǒng)一的入口的。

在這種場景下如果企業(yè)了Hystrix限流熔斷，那么也僅僅是對內(nèi)部的微服務(wù)模塊組件間的消費調(diào)用進行控制。而對于外部APP限流，仍然還需要啟用網(wǎng)關(guān)上的限流熔斷功能。

微服務(wù)架構(gòu)和容器云集成的集群和負(fù)載均衡

最后談下微服務(wù)架構(gòu)和Kubernetes+Docker容器云集成后的服務(wù)發(fā)現(xiàn)和負(fù)載均衡問題。

前面談到在采用Eureka服務(wù)注冊中心的時候，對于同一個微服務(wù)模塊A，我們可以啟動多個微服務(wù)實例，不同的端口號。在端口啟動后通過Eureka來實現(xiàn)服務(wù)的自動注冊和發(fā)現(xiàn)。然后通過Ribbon來實現(xiàn)服務(wù)訪問的負(fù)載均衡處理。

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

但是在DevOps持續(xù)集成下，在實施Kubernetes+Docker容器云后，我們可以通過k8s來實現(xiàn)微服務(wù)節(jié)點資源的動態(tài)擴展。擴展的Pod資源統(tǒng)一由Kubernetes來實現(xiàn)集群負(fù)載均衡均衡，即對外只需要通過Node+端口號訪問即可。

所以在這個時候?qū)嶋H有兩種做法。

做法1：不再使用Eureka服務(wù)注冊和發(fā)現(xiàn)

在這種時候，不再使用Eureka服務(wù)注冊發(fā)現(xiàn)，而是通過Kubernates動態(tài)部署后的VIP進行訪問，由Kubernates來進行后臺節(jié)點的負(fù)載均衡。

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

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

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

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

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

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

如果微服務(wù)模塊全部是通過Kubernetes部署到Docker容器里面，那么我們可以看到完全可以在k8s進行鏡像制作和容器部署的時候?qū)ideCar的內(nèi)容附加到具體的部署包里面實現(xiàn)集成。

簡單來說，就是：

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