本文主要是《微服務架構設計模式》的摘抄筆記，對於想了解微服務架構是否適用於自己系統的朋友，可以一看：
一、寫在最前面
第一、編寫簡潔的代碼和使用自動化測試至關重要，因爲這是現代軟件開發的基礎。
第二、關注微服務的本質，即服務的分解和定義，而不是技術，如容器和其他工具。
第三、確保你的服務鬆耦合，並且何以獨立開發、測試和部署，不要搞成分佈式單體，那將會是巨大的災難。
第四、不能只是在技術上採用微服務架構。擁抱DevOps的原則和實踐，在組織結構上實現跨職能的自治團隊，這必不可少。
二、你是否也遇到如下問題（單體地獄）
1. 被抱怨無法按時交付：業務人員總是抱怨爲何研發團隊要一次次錯過產品的關鍵交付期限，即使技術團隊已經使用了模塊化開發、敏捷開發。
2. 一直糾結維持現狀還是重構改變：如何同時解決眼前的各種項目需求問題和系統性地採納微服務架構。
3. 現有系統已成爲“泥球模式”：隨意架構的、龐大的、草率的、佈滿了膠帶和線路，如同意大利麪條一般的代碼叢林。
4. 過度的複雜性讓後繼開發者爲難：因爲“泥球模式”下的長期任性發展，系統本身過於龐大和複雜，以至於任何一個開發者都很難理解它的全部。因此，修復軟件中的問題和正確地實現新功能就變得困難且耗時，各種交付截止時間都可能被錯過。並且，由於代碼庫太難於理解，因此開發人員在更改時更容易出錯，每一次更改都會讓代碼庫變得更復雜、更難懂。
5. 開發速度緩慢：巨大的項目會把IDE工具搞慢、構建一次系統需要很長時間、每次啓動也需要很長時間、測試更需要很長時間（因代碼庫的複雜性和唯一性，導致任何一個小改動，都需要全量回歸測試）、把代碼更改部署到生產環境的時間變得更長。因此，從編輯到構建、運行再到測試這個週期花費的時間越來越長，這嚴重地影響了團隊的工作效率。
6. 敏捷實踐不完整：衆多開發人員都向同一個代碼庫提交代碼更改，這常常使得這個代碼庫的構建結果處於無法交付的狀態。當團隊嘗試採用功能分支來解決這個問題時，帶來的是漫長且痛苦的合併過程。
7. 難以擴展：在對應用進行橫向擴展時也遇到挑戰，因爲不同模塊對資源的需求時相互衝突的。
8. 生產系統缺乏可靠性：因無法進行全面徹底的測試，且系統缺乏故障隔離（因爲所有模塊都在同一個進程中運行）,導致一出問題所有實例都受影響。
9. 長期依賴某個可能已經過時的技術棧：團隊必須長期使用一套相同的技術棧，即使這個技術棧正在被廢棄或者過時，在單體應用上採用新技術或者嘗試新技術都是極其昂貴和高風險的，因爲這個應用必須被徹底重寫。
三、微服務架構的基本特點，以及應該在什麼情況下使用微服務架構
軟件架構其實對功能性需求影響並不大，架構的重要性在於它影響了應用的非功能性需求，也稱爲質量屬性。隨着“泥球模式”下系統的增長，各種質量屬性和問題都浮出水面，最顯著的就是影響軟件交付速度的可維護性、可擴展性和可測試性。
專業過硬的團隊可以減緩項目陷入單體地獄的速度，比如努力維護模塊化應用、編寫自動化測試等。但是，依然無法避免單體應用協同工作的問題、也無法解決日益過時的技術棧問題。最終只是延緩項目陷入單體地獄的速度。要從根本上解決這一問題，必須遷移到新架構：微服務架構。
1. 微服務的三個維度：對請求的負載均衡、對用戶的負載均衡、以及對服務的模塊化。
2. 每個服務都擁有自己的數據庫：服務之間是鬆耦合的，它們僅通過API進行通信。當然，這並不意味着每個服務都需要一個獨立的數據庫服務器。
優點：
1）使大型的複雜應用程序可以持續交付和持續部署
它擁有持續交付和持續部署所需要的可測試性、可部署性，並且開發團隊能夠自主且鬆散耦合。
因此帶來的價值有：
1. 業務同事滿意：縮短了產品交付時間。
2. 客戶滿意：提供可靠服務。
3. 項目組成員滿意：可以花更多時間來提供有價值的功能，而不是四處擔任救火隊員。
2）每個服務都相對較小並容易維護。
3）服務可以獨立部署和擴展
每個服務都可以部署在適合它們需求的硬件上，例如有些組件是CPU運算密集型的，有些可能需要更多的內存空間。
4）微服務架構可以實現團隊的自治。
5）更容易實驗和採納新的技術
當開發一個新的服務時，開發者可以自由選擇適用於這個服務的任何語言和框架。
6）更好的容錯性。
缺點：
1）服務的拆分和定義是一項挑戰
要儘量避免構建出一個分佈式的單體應用：一個包含了一大堆互相之間緊耦合的服務，卻又必須部署在一起的所謂分佈式系統。
2）分佈式系統帶來的各種複雜性，使開發、測試和部署變得更困難
服務必須使用進程間通信機制。必須設計服務來處理局部故障，並處理遠程服務不可用或出現高延遲的各種情況。
基於微服務的應用程序必須使用所謂的Saga來維護服務之間的數據一致性，必須使用API組合或CQRS視圖實現查詢。
運維複雜性：
1. 自動化部署工具，例如Netflix Spinnaker
2. 產品化的PaaS平臺，例如Pivotal Cloud Foundry或Red Hat OpenShift
3. Docker容器編排平臺，例如Docker Swarm或Kubernetes
3）當部署跨越多個服務的功能時，需要謹慎地協調更多開發團隊
當部署跨越多個服務的功能時，必須制定一個發佈計劃，把服務按照依賴關係進行排序。
4）開發者需要思考到底應該在應用的什麼階段使用微服務架構
在開發應用程序的第一個版本時，通常不會遇到需要微服務架構才能解決的問題，反而，使用精心設計的分佈式架構將減緩開發速度。所以，針對初創公司來說，最大的問題通常是在快速發展業務模型和維護一個優雅的應用架構之間的取捨。特別是在開發MVP場景時，初創公司的初版應用程序是用來獲取市場或投資人的反饋、進行快速試錯的，這個階段不應花費太多時間在微服務架構這樣的事情上。