初識微服務架構

        微服務架構說白了就是一種系統架構上的設計風格，它的主要特點就是將本來獨立的系統、大而全的系統拆分紅若干個小型服務，這些小服務都是一個獨立的進程在運行，並且服務之間能夠經過HTTP接口互相調用以保障業務的完整性。拆分紅若干小型服務後，每一個服務均可以單獨管理了，這樣上線後有個別服務有bug或需求變動時，只須要動須要變更的服務便可，避免了獨立系統 牽一髮而動全身的狀況。並且服務獨立部署、獨立管理，有服務負載增長時，擴展該服務的節點便可，並且擴展是動態、無感知的。

        那麼首先要考慮的問題就是怎麼拆分原來的系統？有什麼拆分原則嗎？

        1. 業務因素：拆分服務時首先考慮業務的獨立性和專業性，也就是面向業務的，按照業務功能合理的規劃每一個服務的邊界。每一個服務都是一個獨立獨立服務內部的要知足高內聚的特色，就是說每一個服務內部的依賴性要高，而服務之間要知足低耦合的原則。好比電商系統中的訂單服務、庫存服務、購物車服務等。

        2. 架構組織獨立性：服務拆分後，每一個服務最好是獨立的團隊來進行維護，不容許出現團隊之間交叉維護的狀況。每一個服務都維護着本身的數據存儲、業務開發、自動化測試案例以及獨立的部署機制。

        3. 投入產出：服務拆分後的運營成本不能高於拆分前的成本。

        運營成本我這裏想到兩方面，一是服務器、網絡等硬件成本，二是運維成本。

        硬件成本：獨立系統時期，咱們擴展服務性能的方式一般是提升服務器性能、作集羣；而到了微服務時代，每一個服務都是獨立部署，這樣就能夠根據每一個服務的負載程度不一樣，單獨擴展負載高的服務便可，沒必要浪費多餘的服務器資源了。

        再說運維成本，無需置疑，服務多了，管理的服務器多了，運維工做量確定比原來高了，但成本必定上升了嗎 ？這個能夠說上升有限或跟原來差很少，緣由就是自動化運維技術的出現。像jenkins這類自動化工具的出現，以及配合spring boot工程的構建方式，配合以maven、git等工具，使得服務只須要一鍵部署。

        好了，再把話題拉回來。繼續介紹分佈式架構，開始提了分佈式的一些好處後，咱們再來講說使用分佈式的缺點都有哪些。

•  管理成本的增長。服務拆分的多了，開發團隊也就多了，團隊多了管理成本必然增長了。
• 運維的新挑戰：雖說自動化運維技術的出現幫忙解決了很多運維的工做，可是一旦服務除了問題，解決起來多是多個團隊之間的協做，增長了問題解決的複雜性。
• 接口的一致性。接口是服務對外提供的訪問入口，以實現業務邏輯。可是當業務變動或其餘狀況致使的接口變動，須要調用方也要根據變動來配合接口的變動和部署。咱們須要更完善的接口和版本管理，或者嚴格遵照開閉原則（開閉原則就是說接口的設計，只有接口有bug時才能修改，若是有新特性、功能則須要新的接口來實現）。
• 分佈式的複雜性。拆分後的服務是獨立進行運行的，服務之間的通訊時網絡延遲、分佈式事務、異步消息等問題接踵而來。分佈式事務如今能夠說是一個世界性難題，CAP定理中能夠窺的分佈式的複雜度遠比獨立服務的事務來的複雜。關於分佈式事務，後續會有討論。

        總結本章的內容，咱們開始說道系統架構從獨立服務發展到了微服務時代，分佈式的架構爲軟件帶來了不少好處，如服務的拆分、獨立部署、獨立管理、節點動態擴展等好處。而後對於如何拆分服務，給出了一些拆分原則。最後，把分佈式架構帶來的挑戰和問題作了說明，這些也是咱們從此使用分佈式架構時須要注意的地方。