《微服務設計》讀書筆記

導讀：《微服務設計》是一本很是出彩的技術書籍，從可讀性、實戰技術乾貨方面都很是優秀，甚至讓我想起了曾經讀《深刻理解計算機系統》《UNIX編程藝術》這類經典好書時的感受。如下是我作的一些歸納性的讀書筆記，很是但願你們能閱讀全書，挖掘更多知識。

---

1、什麼是微服務：就是一些協同工做的小而自治的服務。

• 很小，專一於作好一件事：根據業務的邊界來肯定服務的邊界。
• 自治性：一個微服務就是一個獨立的實體。服務之間均經過網絡調用進行通訊，從而增強了服務之間的隔離性，避免緊耦合。這些服務應該能夠彼此獨立進行修改，而且某一個服務的部署不該該引發該服務消費方的變更。 

  2、微服務的主要好處

• 技術異構性：能夠採用不一樣的技術棧、語言、數據庫或者框架。
• 彈性：彈性工程學的一個關鍵概念是艙壁。若是系統中的一個組件不可用了，但並無致使級聯故障，那麼系統的其餘部分還能夠正常運行。
• 擴展：使用較小的多個服務，則能夠只對須要擴展的服務進行擴展，這樣就能夠把那些不須要擴展的服務運行在更小的、性能稍差的硬件上。
• 簡化部署：在微服務架構中，各個服務的部署是獨立的，這樣就能夠更快地對特定部分的代碼進行部署。
• 與組織結構相匹配：微服務架構能夠很好地將架構與組織結構相匹配，避免出現過大的代碼庫，從而得到理想的團隊大小及生產力。
• 可組合性：能夠根據不一樣的目的組合不一樣粒度的服務爲客戶提供功能。

  3、微服務的原則

• 圍繞業務概念建模
  經驗代表，圍繞業務的界限上下文定義的接口，比圍繞技術概念定義的接口更加穩定。針對系統如何工做這個領域進行建模，不只能夠幫助咱們造成更穩定的接口，也能確保咱們可以更好地反映業務流程的變化。使用界限上下文來定義可能的領域邊界。
• 接受自動化文化
  微服務引入了不少複雜性，其彙總的關鍵部分是，咱們不得無論理大量的服務。解決這個問題的一個關鍵方法是，擁抱自動化文化。前期花費必定的成本，構建支持微服務的工具是頗有意義的。自動化測試必不可少，由於相比單塊系統，確保咱們大量的服務能正常工做是一個更復雜的過程。調用一個統一的命令行，以相同的方式把系統部署到各個環境是一個頗有用的實踐，這也是採用持續交付對每次提交後的產品質量進行快速反饋的一個關鍵部分。
  考慮使用環境定義來幫助你明確不一樣環境間的差別，但同時保持使用統一的方式進行部署的能力。考慮建立自定義鏡像來加快部署，而且建立全自動化不可變服務器，這會更容易定位系統自己的問題。
• 隱藏內部實現細節
  爲了使一個服務獨立於其餘服務，最大化獨自演化的能力，隱藏實現細節相當重要。限界上下文建模在這方面能夠提供幫助，由於它能夠幫助咱們關注哪些模型應該共享，哪些應該隱藏。服務還應該隱藏它們的數據庫，以避免陷入數據庫耦合，這在傳統的面向服務的架構中也是最多見的一種耦合類型。使用數據泵或事件數據泵，將跨多個服務的數據整合到一塊兒， 以實現報表的功能。 
  在可能的狀況下，儘可能選擇與技術無關的API。這能讓你自由地選擇使用不一樣的技術棧。請考慮使用REST，它將內部和外部的實現細節分離方式規範化，即便是使用RPC，你仍然能夠採用這些想法。
• 讓一切都去中心化
  爲了最大化微服務能帶來的自治性，咱們須要持續尋找機會，給擁有服務的團隊委派決策和控制權。在這個過程初期，只要有可能，就嘗試使用資源自助服務，容許人們按需部署軟件，使開發和測試儘量簡單，而且避免讓獨立的團隊來作這些事。 
  在這個過程當中，確保團隊保持對服務的全部權是重要的一步，理想狀況下，甚至可讓團隊本身決定何時讓那些更改上線。使用內部開源模式，確保人們能夠更改其餘團隊擁有的服務，不過請注意，實現這種模式須要不少的工做量。讓團隊與組織保持一致，從而使康威定律起做用，並幫助正在構建面向業務服務的團隊，讓他們成爲其構建的業務領域的專家。一些全局的引導是必要的，嘗試使用共同治理模型，使團隊的每一個成員共同對系統技術願景的演化負責。
  像企業服務總線或服務編配系統這樣的方案，會致使業務邏輯的中心化和啞服務，應該避免使用它們。使用協同來代替編排或啞中間件，使用智能端點確保相關的邏輯和數據，在服務限界內能保持服務的內聚性。
• 可獨立部署
  咱們應該始終努力確保爲服務能夠獨立部署。甚至當須要作不兼容更改時，咱們也應該同時提供新舊兩個版本，容許消費者慢慢遷移到新版本。這可以幫助咱們加快新功能的發佈速度。擁有這些微服務的團隊，也能愈來愈具備自治性，由於他們不須要在部署過程當中不斷的作編配。 當使用基於RPC的集成時，避免使用像Java RMI提供的那種使用生成的樁代碼，緊密綁定客戶端/服務器的技術。
  經過採用單服務單主機模式，能夠減小部署一個服務引起的反作用，好比影響另外一個徹底不相干的服務。請考慮使用藍/綠部署或金絲雀部署技術，區分部署和發佈，下降發佈出錯的風險。使用消費者驅動的契約測試，在破壞性的更改發生前捕捉它們。
  請記住，你能夠更改單個服務，而後把它部署到生產環境，無需聯動地部署其餘任何服務，這應該是常態，而不是例外。你的消費者應該本身決定什麼時候更新，你須要適應他們。
• 隔離失敗
  微服務架構能比單塊架構更具彈性，前提是咱們瞭解系統的故障模式，並作出相應的計劃。若是咱們不考慮調用下游可能會失敗的事實，系統會遭受災難性的級聯故障，系統也會比之前更脆弱。
  當使用網絡調用時，不要像使用本地調用那樣處理遠程調用，由於這樣會隱藏不一樣的故障模式。因此確保使用的客戶端庫，沒有對遠程調用進行過分的抽象。
  若是咱們的心中有反脆弱的信條，預期在任何地方都會發生故障，這說明咱們正走在正確的路上。請確保正確設置你的超時，瞭解什麼時候及如何使用艙壁和斷路器，來限制故障組件的連帶影響。若是系統只有一部分行爲不正常，要了解其對用戶的影響。知道網絡分區可能意味着什麼，以及在特定狀況下犧牲可用性或一致性是不是正確的決定。
• 高度可觀察
  咱們不能依靠觀察單一服務實例，或一臺服務器的行爲，來看系統是否運行正常。相反，咱們須要從總體上看待正在發生的事情。經過注入合成事務到你的系統，模擬真實用戶的行爲，從而使用語義監控來查看系統是否運行正常。聚合你的日誌和數據，這樣當你遇到問題時，就能夠深刻分析緣由。而當須要重現使人討厭的問題，或僅僅查看你的系統在生產環境是如何交互時，關聯標識能夠幫助你跟蹤系統間的調用。

  4、對於微服務的建議

• 考慮首先先構建單塊系統，當穩定後再進行拆分
  你越不瞭解一個領域，爲服務找到合適的限界上下文就越難。服務的界限劃分錯誤，可能致使不得不頻繁地更改服務間的協做，而這種更改爲本很高。因此，若是你不瞭解一個單塊系統領域的話，在劃分服務以前，第一件事是花一些時間瞭解系統是作什麼的，而後嘗試識別出清晰的模塊邊界。另外，對已有的東西進行分類，要比對不存在的東西進行分類要容易得多。
• 演進式架構理念
  微服務架構會給你帶來更多的選擇，也須要你作更多的決策。相比簡單的單塊系統，在微服務的世界中，作決策是一個更爲常見的活動。你必定會在一些決策上出錯，因此儘可能縮小每一個決策的影響範圍。即便錯了，也只會影響系統的一小部分。學會擁抱演進式架構的概念，在這種概念下，系統會在你學到一些新東西以後擴展和變化。不要去想大爆炸式的重寫，取而代之的是隨着時間的推移，逐步對系統進行一系列更改，這樣作能夠保持系統的靈活性。
• 一樣很重要的一點：微服務不是銀彈。

  5、對於架構師的見解

• 演化式架構師：就如同城市規劃師（優化城市佈局，使其易於現有居民生活，同時也考慮一些將來的因素），應該設計出一個合理的框架，在這個框架下能夠慢慢演化出正確的系統；要專一在大方向上，只在頗有限的狀況下參與到很是具體的實現中來。他們須要保證系統不但可以知足當前的需求，還可以應對未來的變化。並且他們還應該保證在這個系統上工做的開發人員要和使用這個系統的用戶同樣開心。
• 一個演化式架構師應該承擔的職責：
  • 願景：確保在系統級有一個通過充分溝通的技術願景，這個願景應該能夠幫助你知足客戶和組織的需求。
  • 同理心：理解你所作的決定對客戶和同事帶來的影響。
  • 合做：和儘可能多的同事進行溝通，從而更好地對願景進行定義、修訂及執行。
  • 適應性：確保你的客戶和組織須要的時候調整技術願景。
  • 自治性：在標準化和團隊自治之間尋找一個正確的平衡點。
  • 治理：確保系統按照技術願景的要求實現。