什麼是微服務

首先微服務並沒有一個官方的定義，想要直接描述微服務比較困難，我們可以透過對比傳統WEB應用，來理解什麼是微服務。

傳統的WEB應用核心分為業務邏輯、介面卡以及API或透過UI訪問的WEB介面。業務邏輯定義業務流程、業務規則以及領域實體。介面卡包括資料庫訪問元件、訊息元件以及訪問介面等。一個打車軟體的架構圖如下：

儘管也是遵循模組化開發，但最終它們會打包並部署為單體式應用。例如Java應用程式會被打包成WAR，部署在Tomcat或者Jetty上。

這種單體應用比較適合於小專案，優點是：

開發簡單直接，集中式管理基本不會重複開發功能都在本地，沒有分散式的管理開銷和呼叫開銷

當然它的缺點也十分明顯，特別對於網際網路公司來說：

開發效率低：所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷程式碼維護難：程式碼功能耦合在一起，新人不知道何從下手部署不靈活：構建時間長，任何小修改必須重新構建整個專案，這個過程往往很長穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉擴充套件性不夠：無法滿足高併發情況下的業務需求小結

所以，現在主流的設計一般會採用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連線的微服務。一個微服務完成某個特定功能，比如乘客管理和下單管理等。每個微服務都有自己的業務邏輯和介面卡。一些微服務還會提供API介面給其他微服務和應用客戶端使用。

每個業務邏輯都被分解為一個微服務，微服務之間透過REST API通訊。一些微服務也會向終端使用者或客戶端開發API介面。但通常情況下，這些客戶端並不能直接訪問後臺微服務，而是透過API Gateway來傳遞請求。API Gateway一般負責服務路由、負載均衡、快取、訪問控制和鑑權等任務。

微服務架構的優點

微服務架構有很多重要的優點。首先，它解決了複雜性問題。它將單體應用分解為一組服務。雖然功能總量不變，但應用程式已被分解為可管理的模組或服務。這些服務定義了明確的RPC或訊息驅動的API邊界。微服務架構強化了應用模組化的水平，而這透過單體程式碼庫很難實現。因此，微服務開發的速度要快很多，更容易理解和維護。

其次，這種體系結構使得每個服務都可以由專注於此服務的團隊獨立開發。只要符合服務API契約，開發人員可以自由選擇開發技術。這就意味著開發人員可以採用新技術編寫或重構服務，由於服務相對較小，所以這並不會對整體應用造成太大影響。

第三，微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過後立即部署。所以微服務架構也使得CI／CD成為可能。

最後，微服務架構使得每個服務都可獨立擴充套件。我們只需定義滿足服務部署要求的配置、容量、例項數量等約束條件即可。比如我們可以在EC2計算最佳化例項上部署CPU密集型服務，在EC2記憶體最佳化例項上部署記憶體資料庫服務。

第一代微服務框架

Spring Cloud

Spring Cloud為開發者提供了快速構建分散式系統的通用模型的工具（包括配置管理、服務發現、熔斷器、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、領導選舉、分散式會話、叢集狀態等）。

Dubbo

Dubbo是一個阿里巴巴開源出來的一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。

下一代微服務：Service Mesh？

Service Mesh

Service Mesh又譯作“服務網格”，作為服務間通訊的基礎設施層。如果用一句話來解釋什麼是Service Mesh，可以將它比作是應用程式或者說微服務間的TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心TCP/IP這一層（比如透過 HTTP 協議的 RESTful 應用），同樣使用Service Mesh也就無須關係服務之間的那些原來是透過應用程式或者其他框架實現的事情，比如Spring Cloud、OSS，現在只要交給Service Mesh就可以了。

2018確實是微服務大發展的一年，特別是spring cloud框架在spring boot 2.0的支援下，配置和使用都方便了很多，但是，微服務不僅僅是把功能拆分而已，它對設計、實施、部署、運維甚至團隊的組織結構都有很大的影響。

下面淺談一點自己的感受：

對設計的影響，傳統的單體式專案，設計時大都是按照分層的思維來進行的，在同一層上，各種功能是聚合的，如果是小專案還OK，大專案經常出現牽一髮而動全身的情況，給維護帶來了很大的困難。但是在微服務下，更多的是按照領域驅動設計的思路，一個領域設計成一個獨立的微服務，介面、快取、持久化等相關動作都在該領域內，對外提供公共的服務，更易於維護。對部署的影響，微服務透過註冊中心的機制，把服務提供方和消費方隔離開來，從而可以獨立的部署各個服務，結合服務呼叫的負載平衡機制，可以透過部署多個服務例項的方式，進行不停機升級，就像開著車換輪子一樣，服務消費方感覺不到服務提供方的服務已經升級了。對運維的影響，這一點更多的是被動的影響，只說一個簡單的例子，就是系統日誌，原來單體的時候日誌在一個地方出來，現在使用微服務，日誌會在多個甚至幾十個微服務部署點出現，這直接就要了運維的老命了，所以日誌的集中處理就是必須要做的事情了，這點也有成熟的方案，使用ELK stack能完美的解決這個問題，代價就是增加了對elasticsearch、logstash、kibana這三個服務本身的維護。對配置的影響，這一點類似於日誌的集中處理，也可以對每個微服務的配置進行集中管理，spring cloud提供了內建解決方案，當然也有代價，如果不是特別多的微服務，可以不使用集中配置。對團隊的影響，這一點非常明確，應該算是積極的影響，就是可以透過獨立的小團隊維護單個的微服務，小團隊負責所有的和微服務相關的設計、開發、運維，不需要頻繁的和其他團隊互動，只要保證自己的服務穩定即可。微服務雖然能解決很多事情，但是也有自己的應用領域，也有不適合的地方，仔細分析自己的專案，根據利弊取捨，決定專案的具體開發方式。