微服務架構入門，一些具有代表性的問題

看了一下，覺得這些問題比較有代表性，很多準備開始做微服務架構的企業或個人都有類似的疑問，因此針對這些問題寫點東西，希望對一些微服務入門者有所幫助。

（1）如何將當前的產品拆解為微服務（組件），每個微服務應包括哪些元素？

要把單體式應用拆分成微服務組件，並沒有一個具像的標準說這個組件應該包括哪些元素。而是需要從業務的角度去分析：某一些功能是否邏輯相對獨立、可復用性高、使用頻度高等等，根據這些因素判斷是否該拆分出來作為一個微服務組件。

微服務設計強調服務的獨立性：不同微服務使用不同的數據，與外部交互通過消息或API而不是耦合的依賴關係;此外，微服務組件的設計需要把握「微」的度，所以不宜在基礎的功能上做過多的堆疊，否則每個微服務組件可能又變成了大的單體應用。

具體來說，微服務設計需要可從以下幾個方面著手：

• 實現前後端分離，可把代碼分為前端、服務層、底層代碼；

• 根據業務邏輯及技術層面的系統架構綜合考慮，抽取模塊成服務;

• 打造服務間的輕量通信基礎組件及協議，例如REST或消息隊列；

• 此外設計時需要注意的很重要的一點是，微服務必須要支持的外部化配置，這種配包括任何佔位符信息到資料庫配置等等，在初始規劃和構建應用原型時，這是必須要考慮的架構內容。

（2）如何搭建合理的微服務匯流排和通信機制？

這個問題提到的所謂的微服務匯流排實際上主要包括兩方面的功能：服務發現和服務調用。

例如阿里開源的Dubbo框架就是一種微服務框架，它藉助Zookeeper等多種註冊中心實現對Provider服務的註冊，並且提供服務發現功能。

Dubbo支持Hessian、WebService、Thrift等方式的RPC遠程服務調用，此外噹噹擴展的dubbox還支持REST API的服務調用方式。

事實上更地道的微服務架構會採用基於非同步通信的調用。在非同步通信中，各服務間彼此依賴，但不會因相互等待結果而導致響應速度緩慢。因此，如果一項服務發生故障，其不會影響到其它服務，瓶頸與單點故障問題也將不復存在。

（3）如何保障負載均衡和微服務系統的整體可靠性？

參考Dubbo提供的ConfigServer的原理，就可知道如何保證微服務系統的負載均衡和整體的可靠性問題了。如果你的系統是Java應用，就可以使用現成的Dubbo，當然你也可以支持根據這個基本原理寫自己的微服務支持框架。

Dubbo的配置中心和每個Server/Client之間會作一個實時的心跳檢測，收集並更新每個Server提供的服務的信息，每個Client的信息。

每個Server啟動時，主動與ConfigServer建立連接，並將自己的IP，提供的服務名稱，埠等信息直接發送給ConfigServer，ConfigServer會更新服務列表。

Client在使用服務的時候根據服務名稱去ConfigServer中獲取服務提供者信息，後面就可以直接調用服務了。當有多個服務提供者的時候，Client根據一定的規則來進行負載均衡，如輪詢，隨機，按權重等。一旦Client使用的服務它對應的服務提供者有變化，ConfigServer就會把最新的服務提供者列表推送給Client，Client重新建立連接。

（4）如何管理服務組件的版本，實現快速部署和無縫升級？

微服務架構下的應用由若干個微服務組件組成，與單體式應用相比其服務組件的版本管理及部署、升級都會變得複雜了，如果全靠手工去做，必然效率底下。

一套完善的開發管理規範，包括開發設計規範、分支管理規範、持續集成規範，再利用Docker容器的天然的特性：「版本控制、可移植性、隔離性」就可以實現組件的版本管理。實質上基於在支持DevOps完整流程的容器雲平台，即可實現整個開發過程及交付中的持續集成、快速部署、灰度發布及無縫升級。

（5）如何搭建配套的服務控制台和管理系統？

在容器雲平台上搭建你的開發、測試及運行環境可實現容器化的持續集成持續部署，即以容器的形式發布應用。平台可以提供容器服務的監控及管理的全套功能，無需自己搭建服務控制台和管理系統。