微服务集成——《微服务设计》读书笔记
一.理想的集成應該是什么樣的？
1.避免破壞性修改
? ? 如果在一個微服務的響應中添加一個字段，服務的消費方不應該受到影響。
2.保證API的技術(shù)無關性
? ? 微服務之間的通信應該是與技術(shù)無關的。
3.使服務的消費方易于使用
? ? 如果消費方使用該服務比登天還難，那么無論該微服務多漂亮都沒用任何意義。但同時，易于使用的服務可能內(nèi)部封裝了很多細節(jié)，這會增加耦合。
4.隱藏內(nèi)部實現(xiàn)細節(jié)
? ? 消費方與服務方的內(nèi)部細節(jié)應該是分開的，如果與細節(jié)綁定，則意味著改變服務內(nèi)部的一些變化，消費方也要跟著修改，這會增加修改的成本。
?
二.數(shù)據(jù)庫是否應該共享
? ? ??共享數(shù)據(jù)庫是最快的集成方式，但這種方式應該避免。
? ? ? 如果是這樣，那么外部的服務則能查看內(nèi)部的實現(xiàn)細節(jié)，并與其綁定在一起，存儲在數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)對所有人來說都是平等的，數(shù)據(jù)庫是一個很大的共享API，那么為了不影響其他服務，必須非常小心地避免修改與其他服務相關的表結(jié)構(gòu)。這樣的情況下，需要做大量的回歸測試來保證功能的正確性。
? ? ? 如果是這樣，消費方與服務方的特定技術(shù)綁定在了一起，如果消費方要從關系型數(shù)據(jù)庫換成非關系型數(shù)據(jù)庫，那么這樣是不容易實現(xiàn)的。這不符合低耦合的原則。
? ? ? 如果是這樣，那么原本由服務方提供的修改，現(xiàn)在可以由各個消費方直接操作數(shù)據(jù)庫來完成，而且每個消費方可能都會有一套自己的修改方法。這不符合高內(nèi)聚的原則。
?
三.服務的協(xié)作：同步or異步？
? ??? 對于同步方式而言，我們可以用請求/響應來概括整個過程，發(fā)起方發(fā)起一個遠程調(diào)用后，發(fā)起方會阻塞自己并等待整個操作的完成，同步對于響應的低延遲有著高要求，因而在現(xiàn)在，這也是不太實際的。我們通常選用方式。
? ? ? 異步的通信模型有兩種。
? ? ? 一種是請求/響應方式，這與同步的不同，它是在發(fā)起一個請求時，同時注冊一個回調(diào)，當服務端操作結(jié)束之后，會調(diào)用該回調(diào)。
? ? ? 一種是基于事件的方式，服務提供方不發(fā)起請求，而是發(fā)布一個事件，然后期待調(diào)用方接收消息，并知道該怎么做，服務提供方不需要知道該或者什么會對此做出響應，這也意味著，你可以在不影響服務提供方的情況下對該事件添加新的訂閱。
?
四.服務的編排與協(xié)同
? ? ??如果你注冊一家網(wǎng)站，它在注冊時做了下面3件事：
? ? ? （1）在客戶的積分賬戶上創(chuàng)建一條記錄
? ? ? （2）通過EMS系統(tǒng)發(fā)送一個歡迎禮包
? ? ? （3）向客戶發(fā)送歡迎電子郵件
? ? ? 當考慮實現(xiàn)時，編排是一種架構(gòu)風格，它由一個中心大腦來指導并驅(qū)動整個流程。它可由客戶管理這個服務來承擔，在創(chuàng)建客戶時會跟積分賬戶服務、電子郵件服務及EMS服務通過請求/響應的方式進行通信。客戶管理服務可以對當前進行到了哪一步進行跟蹤，它會檢查積分賬戶是否創(chuàng)建成功、電子郵件是否發(fā)送出去、EMS包裹是否寄出。這種方式的缺點是：客戶管理服務承擔了太多職責，它會成為網(wǎng)關結(jié)構(gòu)的中心和很多邏輯的起點。這樣會導致少量的“上帝”服務，而與其打資產(chǎn)的那些服務通常會淪為貧血的CRUD服務。
? ? ? 另一種實現(xiàn)的風格則是協(xié)同，它僅僅告知各個系統(tǒng)各自的職責，具體的實現(xiàn)留給他們自己。就上例而言，客戶管理服務創(chuàng)建一個事件，郵件服務、積分服務、EMS服務會訂閱這些事件并做相應的處理，如果其他的服務也關心客戶創(chuàng)建這件事情，它們只需要簡單的訂閱該事件即可。這種方式能顯著地消除耦合，但這需要額外做一些監(jiān)控工作，以保證其正確進行。我們可以建一個跟業(yè)務流程相匹配的跟服務的監(jiān)控服務，分別監(jiān)控每個服務。
?
五.服務的版本管理
1.盡可能推遲修改
? ? 比如我們可以使用XPATH來讀取XML，它可以忽略XML的一些修改，Martin Fowler稱之為容錯性讀取器（http://martinfowler.com/bliki/TolerantReader.html）。
? ? 接收消息的一方應盡可能靈活地消費服務，這就是魯棒性原則（https://tolls.ietf.org/html/rfc761），它認為每個模塊都應該寬進嚴出。
2.及早發(fā)現(xiàn)破壞性修改
? ? 盡量對修改的影響進行全面的回歸。
3.使用主義化的版本管理
? ? 每個服務的版本號支持：Major.Minor.Patch的格式，其中Major的改變意味著其中包含著向后不兼容的修改；Minor的改變意味著有新功能的加入但應該是向后兼容；Patch的改變代表對已有功能的缺陷修復。
4.不同版本的接口共存
? ? 當不得不這么做時，我們的生產(chǎn)環(huán)境可以同時存在接口的新老版本。
假如一個接口存在著V1、V2、V3三種版本，我們可以在所有對V1的請求轉(zhuǎn)換給V2，然后V2轉(zhuǎn)換給V3，這樣是一種平滑的過度，首先擴張服務的能力，對新老兩種都支持，然后等老的消費者都采用了新的方式，再通過收縮API去掉舊的功能。
我們也可以在URI中存放版本信息，但同時我們需要一套方法來對不同的請求進行路由。
5.不同版本的服務共存
? ? 短期內(nèi)同時使用兩個版本的服務是合理的，尤其是當你做藍綠部署或者金絲雀發(fā)布時，在這些情況下，不同版本的服務可能只會存在幾分鐘或者幾個小時，而且一般只會有兩個版本。升級消費者到新版本的時間趙長，就越應該考慮在同一個微服務中暴露兩套API的做法。
?
六.服務的UI管理
? ? ??PC端的程序我們需要關注瀏覽器和分辨率；移動端的程序我們需要關注帶寬和手機的電量，甚至是地區(qū)發(fā)展的水平（也許使用短信登錄更符合當?shù)氐膶嶋H）；在平板上，我們很難使用右鍵操作。我們通過把服務的功能進行不同的組合，可以為Web、移動端、可穿戴設備提供不同的體驗。那么，如何很好的組織起來呢？這就是UI管理面臨的問題。
? ? ? 如果組織一個移動端的頁面，需要調(diào)用20個服務，那么對于移動設備來說會有些吃力，我們可以使用API Getway來緩解這一問題，這種模式下多個底層的調(diào)用會被聚合成一個調(diào)用。
? ? ? 另外一種方式是讓服務暴露出一部分UI，然后只需要簡單地把這些片段組合在一起就可以創(chuàng)建出整體UI。也許音樂商店的訂單管理團隊可以對所有與訂單管理相關的頁面負責。但在最后，我們?nèi)匀恍枰獙⑦@些UI集成在一起，我們可以使用類似服務器模板的技術(shù)來實現(xiàn)。這種方式的優(yōu)勢是可以完成快速修改，但很難保證用戶體驗的一致性，因為各個服務的維護，它們給出的UI風格可能迥異，同時如果你給PC、Web、平板、移動端都提供HTML方式的UI，那么你需要進行一系列的組件嵌入處理，而原生的應用有可能提供更大好的體驗。
?
七.與外系統(tǒng)集成
? ? ??可以在外系統(tǒng)上再包裝出一些服務，對調(diào)用者隱藏細節(jié)，或者捕獲所有的請求，并決定是否路由到遺留代碼還是導向新的代碼中，這種方式可以幫助我們從老系統(tǒng)進行替換，從而避免影響過大的重寫。?
參考
? ? ? 《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）
相關文章：?
微服務的概念——《微服務設計》讀書筆記
微服務架構(gòu)師的職責——《微服務設計讀書筆記》
建模:確定服務的邊界——《微服務設計》讀書筆記
原文地址：http://www.cnblogs.com/gudi/p/6613989.html
.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結(jié)
以上是生活随笔為你收集整理的微服务集成——《微服务设计》读书笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 建模:确定服务的边界——《微服务设计》读
- 下一篇： 离线安装 VS2017 的正确姿势