漫談微服務

前言

印象中從2016年開始「微服務」這個詞逐漸爲人們所熟知，那究竟什麼是微服務呢？

微服務是一種軟件架構風格，一種架構模式，提倡將單體應用劃分爲一組小的服務，服務之間互相協調，互相配合，爲用戶提供最終價值。

每一個服務運行在其獨立的進程中，服務與服務之間採用輕量級的通訊機制互相溝通（一般是基於HTTP的RESTful API），通訊的方式應該與語言無關（C/C++/Golang/Python...），與平臺無關（Windows/Linux/AIX/Android...）。

每一個服務都圍繞這具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

傳統單體應用存在的問題

傳統三層架構圖

三層架構一般包括表示層（UI），業務邏輯層以及數據訪問層。主要面臨的問題：

• 維護成本高。隨着應用程序功能愈來愈多，系統間耦合緊密，團隊愈來愈大，相應的溝通成本，人員協調成本必然會顯著增長。
• 技術選型成本高。各業務領域須要使用相同的技術棧，難於快速應用新技術，阻礙創新。
• 運維成本高。對應用的任何修改都必須整個應用一塊兒部署/升級。
• 可擴展性差。當應用負載增長時，難以水平擴展。例若有些模塊對CPU要求高，有些模塊對IO要求高，綁定在同一個進程裏面就必須同時知足CPU密集型和IO密集型的要求，對機器要求高。
• 一處出現問題會致使整個應用不可用。例如任務一個模塊的邏輯coredump都會致使整個程序崩潰。

微服務架構的優點

微服務架構圖

• 獨立性。每一個服務都是獨立的業務單元，可以被獨立地開發、測試、構建，而且可以被直接部署。
• 單一職責。每一個服務聚焦於某個業務功能，經過清晰的邊界劃分，更容易被團隊理解和維護。
• 技術多樣性。經過服務之間的協做以及輕量級的通訊機制，組織或者團隊能使用合適的語言、工具解決業務問題。

微服務的挑戰

• 分佈式系統的複雜度。微服務架構是一種分佈式系統，從交付的角度出發，構建分佈式系統必然會帶來額外的開銷，例如性能（進程內通訊VS跨機通訊），可靠性（遠程訪問的可靠性），數據一致性（不一樣節點間數據同步問題）等等。

• 運維成本。進程一拆爲多以後，對應的部署成本和監控告警與日誌採集的成本都會成倍上升。
• 服務重構成本。傳統的應用須要重構成微服務，由改形成本。
• 服務治理相關成本。配套的服務註冊與發現，服務網格，服務編排構建。

微服務其實不算是一個全新的概念，早在1996年，Gartner就提出了面向服務架構（SOA），闡述了「對於複雜的企業IT系統，應按照不一樣的、可重用的力度劃分，將功能相關的一組功能提供者組織在一塊兒爲消費者提供服務」。既然相關的概念早就有了，那爲何微服務是最近幾年才火爆起來呢？

由於拋開自動化的CI/CD，相關的服務網關，服務註冊與發現 去空談微服務是沒有辦法精準落地的，得益於2014年Docker的橫空出世解決了應用打包問題，2016年K8S在容器編排大戰中完勝Mesos和Swarm，微服務相關的生態才被完美建設起來，纔有了精準落地的可行性。

微服務通訊

微服務架構的本質是分佈式系統，隨着系統複雜度的增長以及微服務數量的增多，如何選擇輕量級通訊機制、完成服務和服務之間的協做和交互愈加重要。這裏主要比對RPC（例如Thrift），RESTful HTTP，消息隊列（例如beanstalk/redis）。

	RPC（遠程方法調用）	REST	消息隊列
通訊方式	同步通訊	同步通訊	異步通訊
平臺依賴性	強	平臺無關	強
語言支持	好	語言無關	好
學習成本	高	低	高
維護成本	高	低	高

 

若是是同步的通訊方式推薦使用RESTful HTTP通訊方式，輕量級，且與平臺和語言無關，幾乎沒有學習的成本。

若是須要異步的通訊方式推薦使用消息隊列，生產者和消費者異步有利於提升整個系統的性能，可是須要學習消息隊列的用法，而且作好選型，還需考慮消息隊列的高可用等等。