產生 ont 更多 工作 網絡 不可 可能 div 實體

微服務是一些協同工作的小而自治的服務。 1.1、服務小、專註做好一件事 微服務需要根據“內聚性”與“單一性原則”把相關代碼放在一起。（單一性原則：把因相同原因而改變的東西聚合在一起，把因不同原因而改變的東西分離開來） 微服務要足夠小，不要過小。如果你不覺得代碼庫過大，可能它就足夠小了。 服務越小的優點：帶來更好的獨立性。 服務越小的確定：管理大量服務比較復雜。 1.2、自治性 一個微服務就是一個獨立的實體； 每個微服務可以獨立的進行修改，一方服務的部署不應該引起該服務消費者方的變動； 一個微服務可以獨立的部署在PAAS（platform as a service）； 需要避免把多個微服務部署在同一個服務器上； 服務之間通過網絡調用進行通信，加強服務之間的隔離性，避免緊耦合； 服務間暴露的API接口的實現技術應該避免與消費者耦合，選擇與具體技術不相關的API實現方式，以保證技術的選擇不被限制。 2.1、微服務好處 技術異構性：可以在不同微服務使用不同技術，保證各個微服務選擇最合適的實現方式； 彈性：系統中一個組件不可用後，不會影響其他組件的使用，微服務是把單個服務拆分成多個服務，同時各個微服務部署在不同機器上。 擴展：龐大的單塊服務只能作為一個整體進行擴展，其中一個產生性能問題，也需要對整個服務進行擴展。而微服務則可以單獨的修改由性能問題的微服務，方便擴展； 簡化部署：在單塊服務中即使一行代碼修改了，也需要部署整個服務，但是微服務可以避免這種情況，只部署修改的微服務即可； 與組織結構相匹配：微服務可以與組織結構相匹配，保證小團隊更加高效，避免出現過大的代碼塊； 可組織性：每個微服務都可以被多個不同消費者調用，從而達到了可重用、可組合的目的。 對可替代性的優化：使用微服務時，可以單獨的優化某一個服務，所以重寫或者移除一個或者多個微服務的阻礙更小； 3、面向服務的架構 SOA是一種設計方法，其中包括多個微服務，但是SOA並沒有定義通訊協議如何選擇，第三方中間件如何選擇、服務粒度如何確定等問題。 4、其他分解技術 基於微服務的架構有兩個優勢： 它具有足夠小的粒度； 它能在解決問題上給與更多的選擇； 共享庫：不同團隊和服務可以通過庫的形式共享功能；（缺點：庫必須使用同一種語言，每次更新庫都需要重新部署整個進程） 模塊：除了把系統分為不同的服務之外，可以通過在一個進程內部使用模塊進行劃分。

第一章：微服務