項(xiàng)目使用微服務(wù)已有兩年多了，一直停留在使用層面，無意間發(fā)現(xiàn)這本書，想對其理論方面進(jìn)行學(xué)習(xí)，以此讀書筆記做簡要記錄。
作者：王磊
成書時(shí)間：2015年10月7日
示例代碼語言：Ruby
運(yùn)行環(huán)境：Mac OS(或Linux)

結(jié)構(gòu)：
第一部分為基礎(chǔ)部分。包括第1章和第2章，概述了三層應(yīng)用架構(gòu)以及微服務(wù)架構(gòu)。
第二部分為實(shí)踐部分。包括第3章至第10章，通過一個(gè)具體的實(shí)例，從頭到尾介紹了一個(gè)服務(wù)從需求到實(shí)現(xiàn)，再到構(gòu)建、部署以及運(yùn)維的整個(gè)過程。
第三部分為進(jìn)階部分。包括第11章至第14章，討論了微服務(wù)的持續(xù)交付、測試策略、通信機(jī)制，并描述了一個(gè)使用微服務(wù)改造遺留系統(tǒng)的真實(shí)案例。

三部分見相互獨(dú)立，但各章節(jié)之前有前后依賴。

第一章 單塊架構(gòu)及其面臨的挑戰(zhàn)

軟件三層架構(gòu)：

• 表示層，聚焦數(shù)據(jù)顯示和用戶交互
• 業(yè)務(wù)邏輯層，聚焦業(yè)務(wù)邏輯處理
• 數(shù)據(jù)訪問層，聚焦數(shù)據(jù)的存儲與訪問

雖然三層架構(gòu)將系統(tǒng)的邏輯分成了三層，但他并不是物理上的分層。也就是說，對于不同層的代碼而言，經(jīng)歷編譯、打包、部署后，所有的代碼最終還是運(yùn)行在同一個(gè)進(jìn)程中。

對于這種功能集中、代碼中心化、一個(gè)發(fā)布包、部署后運(yùn)行在同一進(jìn)程的應(yīng)用程序，我們通常稱之為單塊架構(gòu)應(yīng)用。

單塊架構(gòu)的優(yōu)勢

• 易于開發(fā)，大部分現(xiàn)有程序均采用單塊架構(gòu)，容易理解且為人熟知?，F(xiàn)有IDE也比較多，方便開發(fā)人員開發(fā)、運(yùn)行和調(diào)試等。
• 易于測試，所有功能均在一個(gè)進(jìn)程，一旦部署，可立即進(jìn)行系統(tǒng)測試或功能測試。
• 易于部署，形成一個(gè)軟件包，部署容易
• 易于水平伸縮，更確切地理解其實(shí)是克隆，新建服務(wù)器節(jié)點(diǎn)可直接克隆之前節(jié)點(diǎn)即可。

單塊架構(gòu)面臨的挑戰(zhàn)

• 維護(hù)成本增加，功能越多團(tuán)隊(duì)越大，溝通成、管理成本以及協(xié)調(diào)成本必然會顯著增加。另外組合缺陷也會隨之增加，分析、定位、修復(fù)都將變得越發(fā)復(fù)雜。
• 持續(xù)交付周期長，隨著程序功能越來越多，代碼越來越復(fù)雜，構(gòu)建和部署的時(shí)間也會相應(yīng)增加。在修改以及提交代碼時(shí)，都會觸發(fā)已部署好的流水線，讓其進(jìn)行代碼檢查（包括編譯、測試、代碼檢查、無害化驗(yàn)證等）。隨著代碼越多，功能驗(yàn)證越多，也就意味著提交所需時(shí)間越來越長。
• 新人培養(yǎng)周期長，熟悉功能、代碼、環(huán)境都需要更長的周期。
• 技術(shù)選型成本高，隨著復(fù)雜性的增加，如果團(tuán)隊(duì)希望嘗試引入新的架構(gòu)、技術(shù)，或者對現(xiàn)有技術(shù)棧升級，通常都會面臨不小的風(fēng)險(xiǎn)。
• 可擴(kuò)展性差，垂直擴(kuò)展，水平擴(kuò)展
• 構(gòu)建全功能團(tuán)隊(duì)難，當(dāng)功能越多，必不可少的會按功能劃分任務(wù)，甚至團(tuán)隊(duì)。這樣當(dāng)一段時(shí)間后，會發(fā)現(xiàn)很少有人能掌握全景視圖。

第二章 微服務(wù)架構(gòu)綜述

什么是微服務(wù)

對于微服務(wù)，目前業(yè)界還沒有一個(gè)嚴(yán)格的定義。不過，ThoughtWorks的首席科學(xué)家——馬丁·福勒(Martin Fowler)先生，對微服務(wù)的這段描述，似乎更加通俗易懂：

微服務(wù)是一種架構(gòu)模式，他提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)之間采用輕量級的通信機(jī)制互相溝通（通?；贖TTP的RESTful API）。每個(gè)服務(wù)都圍繞著業(yè)具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠獨(dú)立的部署到成產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建。

https://martinfowler.com/articles/microservices.html

多微才夠微

代碼行數(shù)：不同語言不同特點(diǎn)，代碼行數(shù)無法衡量
重寫時(shí)間：跟個(gè)人能力強(qiáng)相關(guān)，重寫時(shí)間無法衡量
團(tuán)隊(duì)覺得好才是真的好：需要團(tuán)隊(duì)和組織找到平衡點(diǎn)，但應(yīng)遵循以下兩個(gè)基本原則

• 業(yè)務(wù)獨(dú)立性：通過領(lǐng)域模型確定獨(dú)立業(yè)務(wù)
• 團(tuán)隊(duì)自主性：能由不超過10人的全功能團(tuán)隊(duì)進(jìn)行維護(hù)

獨(dú)立性

獨(dú)立性是指在應(yīng)用的交付過程中，開發(fā)、測試以及部署的獨(dú)立

進(jìn)程隔離

理論上能夠?qū)⒍鄠€(gè)服務(wù)部署到同一個(gè)節(jié)點(diǎn)，并讓他們運(yùn)行在不同的進(jìn)程中，但并不推薦這個(gè)做。一方面增加了部署和擴(kuò)展的復(fù)雜度，另一方面會給水平擴(kuò)容帶來麻煩。

誕生背景

容器虛擬化技術(shù)
Docker是一個(gè)開源的應(yīng)用容器（Linux Container）引擎。
優(yōu)勢：

• 更快速的交付和部署
• 更輕松地遷移和擴(kuò)展
• 更簡單的管理

微服務(wù)架構(gòu)與SOA

SOA(Service-Oriented Architecture)：面向服務(wù)架構(gòu)，早在1996年由Gartner提出。對于復(fù)雜的企業(yè)IT系統(tǒng)，應(yīng)按照不同的、可重用的力度劃分，將功能相關(guān)的一組功能提供者組織在一起為消費(fèi)者提供服務(wù)。
SOA與微服務(wù)的區(qū)別

微服務(wù)架構(gòu)是傳統(tǒng)SOA的一個(gè)子集

微服務(wù)的本質(zhì)

• 服務(wù)作為組件：傳統(tǒng)實(shí)現(xiàn)組件的方式是隔離獨(dú)立的部分或抽取公用的部分，構(gòu)建共享庫，從而達(dá)到解耦和復(fù)用的效果。但它通常是語言相關(guān)、平臺相關(guān)，并且運(yùn)行在同一個(gè)進(jìn)程中的。換句話說共享庫的變化意味著整個(gè)應(yīng)用要被更新，并且需要重新部署。如果把微服務(wù)作為組件，則同傳統(tǒng)使用組件方式最大的區(qū)別是，組件可以被獨(dú)立部署。另外一個(gè)優(yōu)點(diǎn)是組件間定義了清晰的、平臺無關(guān)的接口。缺點(diǎn)：耗時(shí)，嚴(yán)重依賴網(wǎng)絡(luò)的可靠性與穩(wěn)定性。
• 圍繞業(yè)務(wù)組織團(tuán)隊(duì)：單塊架構(gòu)按技能劃分團(tuán)隊(duì)，微服務(wù)架構(gòu)按業(yè)務(wù)劃分團(tuán)隊(duì)，團(tuán)隊(duì)中的成員具有多樣性的技能。如康威定律描述。
• 關(guān)注產(chǎn)品而非項(xiàng)目：單塊架構(gòu)大多采用項(xiàng)目模式，即項(xiàng)目啟動時(shí)，從資源池中抽取人員，組成團(tuán)隊(duì)并完成項(xiàng)目。這樣缺乏主人翁意識、沒有有效的獎懲機(jī)制、缺乏產(chǎn)品成就感。微服務(wù)架構(gòu)采用產(chǎn)品模式更傾向于讓團(tuán)隊(duì)負(fù)責(zé)整個(gè)服務(wù)的生命周期。從服務(wù)的分析、開發(fā)、測試、部署、運(yùn)維。You build it, you run it. --Werner Vogels, CTO of Amazon
• 技術(shù)多樣性：在微服務(wù)架構(gòu)中提倡針對不同的業(yè)務(wù)特征選擇合適的技術(shù)方案。
• 業(yè)務(wù)數(shù)據(jù)獨(dú)立：微服務(wù)架構(gòu)提倡服務(wù)自主管理其相關(guān)的數(shù)據(jù)。
• 基礎(chǔ)設(shè)施自動化：微服務(wù)架構(gòu)將應(yīng)用程序本身分成多個(gè)小的服務(wù)，部署和運(yùn)維的成本會隨著服務(wù)的增長成指數(shù)級增長，就需要更穩(wěn)定的基礎(chǔ)設(shè)置自動化機(jī)制，能夠創(chuàng)建運(yùn)行環(huán)境，安裝依賴，部署應(yīng)用等?？山柚萍夹g(shù)。
• 演進(jìn)式架構(gòu)：服務(wù)能獨(dú)立運(yùn)行在不同的進(jìn)程中，并且通過輕量級的通信機(jī)制建立聯(lián)系，這樣在演進(jìn)過程中可先用一個(gè)或幾個(gè)簡單的服務(wù)進(jìn)行試點(diǎn)，可用則推廣，不可用回退成本也比較低。

微服務(wù)不是銀彈

銀彈：是指一項(xiàng)可使軟件工程的生產(chǎn)力在十年內(nèi)提高十倍的技術(shù)或方法
優(yōu)勢：

• 獨(dú)立性
• 單一職責(zé)
• 技術(shù)多樣性

需要考慮的因素：

• 分布式系統(tǒng)的復(fù)雜度
• • 性能
  • 可靠性
  • 異步
  • 數(shù)據(jù)一致性
  • 工具
• 運(yùn)維成本
• • 配置
  • 部署
  • 監(jiān)控與告警
  • 日志收集
• 部署自動化
• DevOps與組織架構(gòu)
• 服務(wù)間的依賴測試
• 服務(wù)間依賴管理

后兩部分，待續(xù)。。。

附：

康威定律

Conway’s law 最初來自于Conway在1967年發(fā)表的論文《How Do Committees Invent?》，之后在《人月神話》這本書中引用了論文的結(jié)論，并命名為康威定律（Conway’s law）得以推廣。

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

我的翻譯：設(shè)計(jì)系統(tǒng)的組織形式受制于產(chǎn)品設(shè)計(jì)，溝通結(jié)構(gòu)也等價(jià)于該組織形式。

我的理解：團(tuán)隊(duì)劃分或者項(xiàng)目組織需要根據(jù)設(shè)計(jì)的產(chǎn)品進(jìn)行組織，而一旦該組織形式確定，其溝通成本也隨之確定。
在文章中，Mike Amundesn總結(jié)了一些核心觀點(diǎn)：

• 第一定律

Communication dictates the design組織溝通方式會通過系統(tǒng)設(shè)計(jì)表達(dá)出來

• 第二定律

There is never enough time to do something right, but there is always enough time to do it over

時(shí)間再多一件事情也不可能做的完美，但總有時(shí)間做完一件事情

• 第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性

• 第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems

大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解