[筆記] Martin Fowler的《Microservices-微服務(wù)》
目錄
- 術(shù)語表
- 微服務(wù)架構(gòu)的特征 / Characteristics of a Microservice Architecture
- 通過服務(wù)組件化 / Componentization via Services
- 圍繞業(yè)務(wù)能力組織 / Organized around Business Capabilities
- 是產(chǎn)品不是項目 / Products not Projects
- 智能端點和啞管道 / Smart endpoints and dumb pipes
- 去中心化治理 / Decentralized Governance
- 去中心化數(shù)據(jù)管理 / Decentralized Data Management
- 基礎(chǔ)設(shè)施自動化 / Infrastructure Automation
- 為失效設(shè)計 / Design for failure
- 進化式設(shè)計 / Evolutionary Design
- 微服務(wù)是未來嗎泌霍？ / Are Microservices the Future?
- 個人感言
Martin Fowler和James Lewis的《Microservices》是第一篇詳細介紹微服務(wù)的文章喳魏。對微服務(wù)進行了定義汤纸，并與傳統(tǒng)架構(gòu)進行了對比煞额，闡述了微服務(wù)的優(yōu)勢矫渔。
- 原文：Microservices - Martin Fowler
- 中文翻譯：微服務(wù)
- 演說視頻@GOTO Berlin 2014
- 學(xué)習(xí)筆記: Martin Fowler的《微服務(wù)》 - Sky Ao
注1：上面的中文翻譯是目前找到的最好的版本，語句通順而準(zhǔn)確嬉探，向作者致敬颠放！
注2：這個所謂好的翻譯允睹，也只是前半段水準(zhǔn)不錯运准，后半段就急劇下滑娶靡，看不下去......
術(shù)語表
| 英文術(shù)語 | 中文 | 備注 |
|---|---|---|
| Microservice | 微服務(wù) | |
| monolithic | 單體 | 和微服務(wù)相對的傳統(tǒng)架構(gòu)模式 |
| Conway's Law | 康威定律 | 組織決定架構(gòu) |
讀書筆記
注：英文原文和翻譯版本請見上面的鏈接豺撑，以下部分為個人學(xué)習(xí)筆記。
微服務(wù)定義：
微服務(wù)架構(gòu)風(fēng)格是一種將一個單一應(yīng)用程序開發(fā)為一組小型服務(wù)的方法欲低，每個服務(wù)運行在自己的進程中米者，服務(wù)間通信采用輕量級通信機制(通常使用HTTP資源API)韭畸。這些服務(wù)圍繞業(yè)務(wù)能力構(gòu)建，并且可通過全自動部署機制獨立部署蔓搞。這些服務(wù)共用一個最小型的集中式的管理胰丁，服務(wù)可用不同的語言開發(fā)，使用不同的數(shù)據(jù)存儲技術(shù)喂分。
和單體服務(wù)器的對比：
單體服務(wù)器是構(gòu)建這樣一個系統(tǒng)最自然的方式锦庸。處理請求的所有邏輯都運行在
一個單一進程中，允許你使用編程語言的基本特性將應(yīng)用程序劃分類蒲祈、函數(shù)和命名空間甘萧。你認(rèn)真地在開發(fā)機上運行測試應(yīng)用程序，并使用部署管道來保證變更已被準(zhǔn)確地測試并部署到生產(chǎn)環(huán)境中讳嘱。該單體的水平擴展可以通過在負載均衡器后面運行多個實例來實現(xiàn)。
單體服務(wù)器的問題：
變更周期被捆綁在一起 —— 即使只變更應(yīng)用程序的一部分酿愧，也需要重新構(gòu)建并部署整個單體沥潭。長此以往，通常將很難保持一個良好的模塊架構(gòu)嬉挡，這使得變更很難只發(fā)生在需要變更的模塊內(nèi)钝鸽。程序擴展要求進行整個應(yīng)用程序的擴展而不是需要更多資源的應(yīng)用程序部分的擴展。
微服務(wù)架構(gòu)風(fēng)格：
構(gòu)建
應(yīng)用程序為服務(wù)套件庞钢。除了服務(wù)是可獨立部署拔恰、可獨立擴展之外，每個服務(wù)都提供一個固定的模塊邊界基括。甚至允許不同的服務(wù)用不同的語言開發(fā)颜懊，由不同的團隊管理。
微服務(wù)架構(gòu)的特征 / Characteristics of a Microservice Architecture
通過服務(wù)組件化 / Componentization via Services
組件的定義：
組件是一個可獨立替換和獨立升級的軟件單元。
微服務(wù)架構(gòu)組件化軟件的主要方式：
分解成服務(wù)河爹，而服務(wù)是一種
進程外的組件匠璧，通過Web服務(wù)請求或RPC機制通信。
使用服務(wù)作為組件而不是使用庫的主要原因：
- 服務(wù)是可獨立部署的
- 更加明確的組件接口：服務(wù)通過明確的遠程調(diào)用機制可以避免組件間的緊耦合
缺點：
- 遠程調(diào)用比進程內(nèi)調(diào)用更昂貴
- 導(dǎo)致遠程API設(shè)計成粗粒度咸这，不便于使用(為了屏蔽一些對用戶透明的內(nèi)部實現(xiàn)細節(jié))
圍繞業(yè)務(wù)能力組織 / Organized around Business Capabilities
康威定律(Conway's Law)：
任何設(shè)計系統(tǒng)(廣泛定義)的組織將產(chǎn)生一種設(shè)計夷恍，他的結(jié)構(gòu)就是該住址的通信結(jié)構(gòu)。 -- Melvyn Conway, 1967
簡單一句話就是：“組織決定架構(gòu)(業(yè)務(wù)架構(gòu))”媳维！
微服務(wù)的組織方式：
微服務(wù)采用不同的分割方法酿雪，劃分成圍繞業(yè)務(wù)能力組織的服務(wù)。這些服務(wù)采取該業(yè)務(wù)領(lǐng)域軟件的寬棧實現(xiàn)侄刽，包括用戶接口指黎、持久化存儲和任何外部協(xié)作。因此唠梨，團隊都是跨職能的袋励，包括開發(fā)需要的全方位技能(用戶體驗、數(shù)據(jù)庫当叭、項目管理)茬故。
建議：
敦促創(chuàng)建單體應(yīng)用程序的大型團隊將團隊本身按
業(yè)務(wù)線拆分
是產(chǎn)品不是項目 / Products not Projects
項目模式：
目標(biāo)是交付將要完成的一些軟件。完成后的軟件被交接給維護組織蚁鳖，然后它的構(gòu)建團隊就解散了磺芭。
微服務(wù)支持者傾向于避免這種模式，而是認(rèn)為一個團隊?wèi)?yīng)該負責(zé)產(chǎn)品的整個生命周期醉箕。
產(chǎn)品模式：
產(chǎn)品思想與業(yè)務(wù)能力緊緊聯(lián)系在一起钾腺。要持續(xù)關(guān)注軟件如何幫助用戶提升業(yè)務(wù)能力，而不是把軟件看成是將要完成的一組功能讥裤。
微服務(wù)相對單體應(yīng)用的優(yōu)勢：
同樣的方法也可以用在單體應(yīng)用程序上放棒，但服務(wù)的粒度更小，使得它更容易在服務(wù)開發(fā)者和用戶之間建立
個人關(guān)系己英。
智能端點和啞管道 / Smart endpoints and dumb pipes
在不同進程間創(chuàng)建通信結(jié)構(gòu)時间螟，智能端點放在哪里？有兩種不同思路：
- 把顯著的智慧強壓進通信機制本身
一個很好的例子就是企業(yè)服務(wù)總線(ESB)损肛，在ESB產(chǎn)品中通常為消息路由厢破、編排(choreography)、轉(zhuǎn)化和應(yīng)用業(yè)務(wù)規(guī)則引入先進的設(shè)施治拿。 - 智能端點和啞管道
微服務(wù)社區(qū)主張另一種方法摩泪，基于微服務(wù)構(gòu)建的應(yīng)用程序的目標(biāo)是盡可能地解耦和盡可能地內(nèi)聚 - 他們擁有自己的領(lǐng)域邏輯，他們的行為更像經(jīng)典Unix理念中的過濾器 - 接收請求劫谅，應(yīng)用適當(dāng)?shù)倪壿嫴a(chǎn)生響應(yīng)见坑。
使用簡單的REST風(fēng)格的協(xié)議來編排嚷掠，而不是使用像WS-Choreography、BPEL或者通過中心工具編制(orchestration)等復(fù)雜的協(xié)議鳄梅。
最常用的兩種協(xié)議：
- 使用REST API的HTTP請求-響應(yīng)和輕量級消息傳送
- 在輕量級消息總線上傳遞消息
把單體變成微服務(wù)：
最大的問題在于通信模式的改變叠国。一種幼稚的轉(zhuǎn)換是從內(nèi)存方法調(diào)用轉(zhuǎn)變成RPC，這導(dǎo)致頻繁通信且性能不好戴尸。相反粟焊，你需要用粗粒度通信代替細粒度通信。
去中心化治理 / Decentralized Governance
集中治理的一個后果是技術(shù)平臺的單一標(biāo)準(zhǔn)化發(fā)展趨勢孙蒙。不是每個問題都是釘子项棠，不是每個問題都是錘子。我們更喜歡使用正確的工具來完成工作挎峦。
把單體的組件分裂成服務(wù)香追，在構(gòu)建這些服務(wù)時可以有自己的選擇。
去中心化治理的最高境界就是亞馬遜廣為流傳的"you build it, you run it"理念：團隊要對他們構(gòu)建的軟件的各方面負責(zé)坦胶，包括724小時的運營*透典。
去中心化數(shù)據(jù)管理 / Decentralized Data Management
DDD(Domain-Driven Design)把一個復(fù)雜域劃分成多個有界的上下文，并且映射出它們之間的關(guān)系顿苇。這個過程對單體架構(gòu)和微服務(wù)架構(gòu)都是有用的峭咒，但在服務(wù)和上下文邊界間有天然的相關(guān)性，邊界有助于澄清和加強分離纪岁，就像業(yè)務(wù)能力部分描述的那樣凑队。
微服務(wù)更傾向于讓每個服務(wù)管理自己的數(shù)據(jù)庫，或者同一數(shù)據(jù)庫技術(shù)的不同實例幔翰，或完全不同的數(shù)據(jù)庫系統(tǒng)漩氨。
分布式事務(wù)：
微服務(wù)架構(gòu)強調(diào)服務(wù)間的無事務(wù)協(xié)作，關(guān)注最終一致性和事后補償遗增。
權(quán)衡：
修復(fù)錯誤的代價是否小于一致性下業(yè)務(wù)損失的代價叫惊？
基礎(chǔ)設(shè)施自動化 / Infrastructure Automation
基于持續(xù)部署(和它的前身持續(xù)集成)，構(gòu)建管線圖：
關(guān)鍵特性：
- 自動化測試
- 自動化部署
- 在生產(chǎn)環(huán)境中管理微服務(wù)
為失效設(shè)計 / Design for failure
使用服務(wù)作為組件的一個后果：
應(yīng)用程序需要被設(shè)計成能夠容忍服務(wù)失效做修。任何服務(wù)調(diào)用都可能因為服務(wù)提供者不可用而失敗霍狰，客戶端必須盡可能優(yōu)雅地應(yīng)對這種失敗(消息方式)。
與單體應(yīng)用設(shè)計相比這是一個劣勢缓待，因為它引入額外的復(fù)雜度蚓耽。
為應(yīng)對隨時可能失敗的服務(wù)渠牲，微服務(wù)：
- 快速檢測故障
- 自動恢復(fù)服務(wù)
- 應(yīng)用程序的實時監(jiān)測：包括性能指標(biāo)(如TPS)和業(yè)務(wù)指標(biāo)(如訂單數(shù))
- 告警系統(tǒng)：通知開發(fā)團隊跟進和調(diào)查
微服務(wù)希望看到為每個單獨的服務(wù)設(shè)置完善的監(jiān)控和日志記錄：
- 控制面板上顯示啟動/關(guān)閉狀態(tài)
- 各種各樣的運營和業(yè)務(wù)相關(guān)指標(biāo)
- 斷路器狀態(tài)
- 當(dāng)前吞吐量和時延
進化式設(shè)計 / Evolutionary Design
分割應(yīng)用的原則：組件可獨立地更換和升級
微服務(wù)強調(diào)可替代性旋炒，通過變更模式來驅(qū)動模塊化：同時變化的東西保持在同一模塊中。系統(tǒng)中很少變更的部分應(yīng)該和正在經(jīng)歷大量擾動的部分放在不同的服務(wù)里签杈。如果你發(fā)現(xiàn)自己不斷地一起改變兩個服務(wù)瘫镇，這是它們應(yīng)該被合并的一個標(biāo)志鼎兽。
微服務(wù)是未來嗎？ / Are Microservices the Future?
Martin Fowler在2014年初寫下這篇文章時铣除，還是“懷著謹(jǐn)慎樂觀的態(tài)度”谚咬。而這之后的一年半時間，業(yè)界對微服務(wù)的接受程度遠遠超過當(dāng)時的預(yù)期尚粘，幾乎可以說是推崇甚至有成為業(yè)界標(biāo)桿的趨勢择卦。
個人感言
去年這篇文章出來不久，就認(rèn)真拜讀過一遍(當(dāng)時還只有英文版)郎嫁，收獲頗多秉继。
一年半之后，細細重溫這篇老文泽铛，還是收獲頗多尚辑。有些當(dāng)時還不是太懂的地方，現(xiàn)在理解的深刻多了盔腔，比如說“康威定律”杠茬。
計劃一兩年之后再回來重讀一遍，很期待屆時會有什么想法和感觸弛随。
