戀

什麼是微服務

首先微服務並沒有一個官方的定義，想要直接描述微服務比較困難，我們可以通過對比傳統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就可以了。

Java高併發框架

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

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

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

關鍵字: 服務 科技 互聯網