[微服務感悟] 服務發現與常見架構
- 2020 年 2 月 13 日
- 筆記
文章目錄
- 什麼是服務發現
- 服務發現原始架構
- 程式內集成網關架構
- 統一網關架構（匯流排架構）
- service mesh微服務架構
這時一篇務虛的博文，主要記錄對微服務發現的感悟。
什麼是服務發現
微服務架構中，服務都運行在許許多多的機器中，調用其他服務時首先需要找到這個服務在哪裡呢，找服務對應的機器的過程就是服務發現。
服務發現原始架構
最初的做法是在程式中寫死服務對應的域名，讓運維人員配置域名解析到對應的ngnix網關，網關做負載均衡，分發到對應伺服器節點。這種做法相當於程式內保存服務對應域名，ngnix做網關，保存伺服器節點地址，並負責負載均衡和轉發。
隨著業務進一步發展，服務越來越多，服務的節點伺服器也越來越多，稍微上點規模的業務，都有20+的服務，每個服務又存在2+個節點伺服器。這時如果服務的域名，服務的節點要發生更改，就需要改動很多文件，甚至需要許多服務重新發版，而且隨著服務多了，總有某些服務會需要發生更改，這存在極大的工作量和風險。所以服務多了，這套就不適用了。
A域名
B域名
生產服務, 項目配置文件中存在其他服務資訊
網關, 負載均衡
A服務節點1
A服務節點2
A服務節點3
網關B
B服務節點1
B服務節點2
程式內集成網關架構
這套架構是在每個程式中都存放所有服務，所有節點的資訊，程式自己做負載均衡。同時存在一個服務中心，它負責同步每個服務的最新節點資訊，註冊服務（當有新服務上線時，像服務中心發送自己的ip和服務名，服務中心添加該條服務資訊），健康檢查（定時發送心跳包到每個服務，對發送不成功的服務，按下線規則做處理），提供查看所有節點資訊的http介面。
這時服務中心就十分重要，如果服務中心掛了，其他服務就不能感知到存在的新的服務變化，所以它一定要高可用。每個服務實際訪問的是本地的服務節點資訊，那麼就一定存在本地和服務中心節點數據不同步的情況，所以從設計上說，這是一個偏向高可用的設計，而不是高一致。
常見的實踐是在框架中即成服務節點資訊同步，服務發現，負載均衡等功能，程式只實現業務員邏輯。spring cloud便是這一套架構，eureka是服務註冊中心，spring cloud框架中集成了服務資訊的同步。
這種架構需要統一的框架支援某套服務節點資訊同步的通訊協議，這會技術棧依賴某一個框架，並不能實現微服務中，每個服務任意使用某個技術棧的願想。如採用spring cloud做微服務技術棧，那麼每個服務都要採用springcloud/boot框架，但是我如果想使用python/go/.net/c++的服務，就不太容易集成到這套架構中去。
統一網關架構（匯流排架構）
這是一種偏向AP的架構，高一致，低可用，每個微服務程式都需要將請求發給服務中心，由服務中心找到對應可用節點，再進行分發。它抽象出的服務中心，負責負載均衡，服務註冊，服務轉發的功能功能。
這套的好處是，服務中心統一管理所有的服務節點資訊，可以保證高一致性，每個服務不用集成負載均衡等模組，不存在框架/程式碼依賴，每個微服務都可以採用各自技術棧，不受限制。
缺點是每個請求都要穿透一次服務中心，有性能損耗；而且服務中心作用太大，一旦掛掉，所有業務都會停止，只適合內網比較穩定的環境中運行。
服務關鍵字
轉發
客服端服務
服務中心
服務A節點1
服務A節點2
服務B節點1
我工作中的某家公司，用的就是這套架構。做法是這樣的，規定統一的發送協議，即採用http做通訊協議，在請求頭中加一個系統code，代表要轉發的系統編號。所有請求都要發給middleware（服務中心）的服務做轉發，middleware中存有所有服務IP地址；每個服務啟動時都會向middleware服務發送註冊資訊；middleware定期向所有服務發送心跳監控服務是否在線；middleware提供統一的負載均衡策略，熔斷策略；middleware提供統一的http介面以供其查詢伺服器資訊，middleware在內網中。
PS：當時設計這套的架構師稱為匯流排架構，後來被綠廠高薪挖過去搞架構了，他說過去推廣這一套。
架構如下，不過我已經離職有段時間了，這個架構應該還能再拆拆，合合。如open-Platform、face功能重合，沒有合併的原因是歷史原因；如middleware可以拆成櫃機基本服務和服務中心。
service mesh微服務架構
service mesh是現在比較火的概念，它的思想和程式內集成網關架構有點像，不過它的網關在每個系統鏡像包中，而不是程式碼/框架集成在程式中，它配合來使用docker會非常方便。服務中心同步每個容器中網關的服務節點資訊，每個程式都向系統/容器內的網關發送請求，網關在進行服務發現和負載均衡，找到對應的容器發送過去。
這套架構也支援每個服務採用各自的技術棧，互不干擾；服務都是通過容器內的網關做轉發，即使服務中心不可用，也能使用，是高可用架構
缺點是沒啟動一個應用，都要重新打一個對應的鏡像包，運維工作更加複雜，必須有集成一整套自動化開發部署工具才行，也就是devops工具箱，只有技術實力強的公司可以試試這套。
