spring cloud系列(一) - 微服務架構介紹

什麼是微服務架構？

微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，并利用簡單的方法使多個小系統互相協作，組合成一個大系統。就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開，并利用輕量化機制（通常為HTTP RESTful API）實作通信。

微服務架構是一種架構模式，它提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務與服務間采用輕量級的通信機制互相協作（通常是基于HTTP協定的RESTful API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立的部署到生産環境、類生産環境等。

微服務架構 ≈ 子產品化開發 + 分布式計算
           

微服務元件及概念

1. 服務注冊：服務提供方将自己調用位址注冊到服務注冊中心，讓服務調用方能夠友善地找到自己。
2. 服務發現：服務調用方從服務注冊中心找到自己需要調用的服務的位址。
3. 負載均衡：服務提供方一般以多執行個體的形式提供服務，負載均衡功能能夠讓服務調用方連接配接到合适的服務節點。并且，節點選擇的工作對服務調用方來說是透明的。
4. 服務網關：服務網關是服務調用的唯一入口，可以在這個元件是實作使用者鑒權、動态路由、灰階釋出、A/B測試、負載限流等功能。
5. 配置中心：将本地化的配置資訊（properties, xml, yaml等）注冊到配置中心，實作程式包在開發、測試、生産環境的無差别性，友善程式包的遷移。
6. API管理：以友善的形式編寫及更新API文檔，并以友善的形式供調用者檢視和測試。
7. 內建架構：微服務元件都以職責單一的程式包對外提供服務，內建架構以配置的形式将所有微服務元件（特别是管理端元件）內建到統一的界面架構下，讓使用者能夠在統一的界面中使用系統。
8. 分布式事務：對于重要的業務，需要通過分布式事務技術（TCC、高可用消息服務、最大努力通知）保證資料的一緻性。
9. 調用鍊：記錄完成一個業務邏輯時調用到的微服務，并将這種串行或并行的調用關系展示出來。在系統出錯時，可以友善地找到出錯點
10. 支撐平台：系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就需要将大部分的工作自動化。現在，可以通過Docker等工具來中和這些微服務架構帶來的弊端。 例如持續內建、藍綠釋出、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經驗，可以這麼說，如果沒有合适的支撐平台或工具，就不要使用微服務架構。

微服務架構的優勢

1. 服務簡單，隻關注一個業務功能 ：單體架構在建構部署和擴充伸縮方面有很大的局限性，其服務端應用就像是一塊鐵闆，笨重且不可拆分，系統中任何程式的改變都需要整個應用重新建構和部署新版本。在進行水準擴充時也隻能整個系統擴充，而不能針對某一個功能子產品進行擴充。

   而微服務架構将系統以元件化的方式分解為多個服務，服務之間相對獨立且松耦合，單一功能的改變隻需要重新建構部署相應的服務即可。

2. 松耦合：微服務架構抛棄了複雜的業務規則編排、消息路由等功能，微服務架構中服務是高内聚的，每個服務都會處理相應的業務，所有的業務邏輯應該盡量在服務内部處理，且服務間的通信盡可能的輕量化。通過微服務架構可以更好的提升各個子產品的可複用性和可組裝性。通過微服務架構更好的實作了原單體應用内部各個元件或子產品的徹底解耦，通過解耦本身也降低了原單體應用内部的複雜度。
3. 更容易水準擴充：微服務架構下實作了單體應用的垂直拆分，可以更加容易的通過廉價的X86伺服器或docker伺服器資源來實作水準擴充。
4. 靈活開發與運維：采用微服務架構可以更好的實作DevOps開發運維一體化，同時因為微服務架構下各個微服務子產品相對獨立和松耦合，是以在後續業務變更的分析和進行中往往能夠更加靈活快速的響應，同時相對影響也最小。可以使研發過程根據靈活和小團隊化，包括和靈活軟體開發最佳實踐更好的比對，每個微服務子產品都可以形成獨立的靈活小團隊進行開發和部署上線
5. 更加自由化：各個微服務之間可以選擇不技術實作，可以根據業務功能進行自由技術選型。

微服務架構的劣勢

1. 分布式系統的複雜性：微服務通過REST API或消息來将不同的服務聯系起來，這在之前可能隻是一個簡單的遠端過程調用。分布式系統也就意味着開發者需要考慮網絡延遲、容錯、消息序列化、不可靠的網絡、異步、版本控制、負載等，而面對如此多的微服務都需要分布式時，整個産品需要有一整套完整的機制來保證各個服務可以正常運轉。
2. 分布式事物管理：由于各個微服務子產品完全相對獨立和松耦合，是以對于跨多子產品業務帶來的分布式事務問題是必須解決或找尋替代方案。特别是在微服務架構下資料庫已經進行了垂直拆分，對于跨庫通路本身的分布式事務一緻性問題是最需要和重視的問題。
3. 隐式接口：服務和服務之間通過接口來“聯系”，當某一個服務更改接口格式時，可能涉及到此接口的所有服務都需要做調整。
4. 部署開銷：由于微服務子產品需要獨立部署，往往涉及到多達上100個容器的安裝和部署和內建等相關工作，這也是需要和Docker內建并實作自動部署的一個原因。
5. 運維開銷：更多的服務也就意味着更多的運維，産品團隊需要保證所有的相關服務都有完善的監控等基礎設施，傳統的架構開發者隻需要保證一個應用正常運作，而現在卻需要保證幾十甚至上百道工序高效運轉，這是一個艱巨的任務。
6. DevOps要求：使用微服務架構後，開發團隊需要保證一個Tomcat叢集可用，保證一個資料庫可用，這就意味着團隊需要高品質的DevOps和自動化技術。而現在，這樣的全棧式人才很少。

7. 異步、測試面臨挑戰：跨程序之間的大量的異步處理、多個微服務之間的整體測試都需要有一整套的解決方案，而現在看起來，這些技術并沒有成熟。

   總而言之，微服務架構有很多吸引人的地方，不過在擁抱微服務之前要認清它所帶來的挑戰。而每一種架構都有其優缺點，我們需要根據項目業務和團隊情況來選擇合适的架構。

微服務架構的使用場景

1. 規模大（團隊超過10人）
2. 業務複雜度高（系統超過5個子子產品）
3. 需要長期演進（項目開發和維護周期超過半年）

總結

單體式的架構更适合輕量級的簡單應用。微服務架構模式可以用來建構複雜應用，當然，這種架構模型也有自己的缺點和挑戰。