產(chǎn)品級微服務(wù)的八大原則課件

1、產(chǎn)品級微服務(wù)的八大原則微服務(wù)的內(nèi)部結(jié)構(gòu)資源(Resources)作為由服務(wù)所暴露的應(yīng)用協(xié)議以及表示域?qū)ο蟮南⒅g的映射器。通常情況下，它們比較輕便，用于檢查請求的完備性，并提供根據(jù)業(yè)務(wù)事務(wù)的輸出來返回一個協(xié)議特定的響應(yīng)。域模型幾乎所有在域模型中的業(yè)務(wù)邏輯都代表了業(yè)務(wù)域。在這些對象中，服務(wù)跨越多個領(lǐng)域進行協(xié)調(diào)，而庫作用于域?qū)嶓w的集合，而且往往持續(xù)性支持。服務(wù)協(xié)作如果一個服務(wù)需要另一服務(wù)進行協(xié)作，那么一些邏輯就需要與外部服務(wù)進行通信。網(wǎng)關(guān)打包域?qū)ο蟮恼埱蠛晚憫?yīng)，封裝消息并傳遞至遠(yuǎn)程服務(wù)。它可能會使用理解底層協(xié)議的客戶機來處理請求-響應(yīng)周期域存儲庫除了最簡單的情況，或當(dāng)一個服務(wù)作為聚合其他服務(wù)所擁

2、有的資源的聚合器之外，微服務(wù)需要能夠在幾個請求之間儲存域的對象。通常這是通過使用對象關(guān)系映射或使用滿足持久性要求的復(fù)雜性的更輕便的數(shù)據(jù)映射器實現(xiàn)。通常情況下，這個邏輯塊被封裝在一組由域存儲庫使用的專用對象中。二、微服務(wù)的誤區(qū)一、數(shù)據(jù)驅(qū)動的遷移反模式可以分割成粗粒度的數(shù)據(jù)和服務(wù)，然后再進一步的分割成更小的微服務(wù)和數(shù)據(jù)，你可能要頻繁地進行服務(wù)調(diào)整：粒度太小，合并微服務(wù)；粒度太大，分割成更小的微服務(wù)。數(shù)據(jù)遷移要比源代碼遷移更復(fù)雜，更容易出錯，理想情況下只為微服務(wù)遷移數(shù)據(jù)一次。理解數(shù)據(jù)遷移的風(fēng)險性是避免這種反模式的第一步。二、超時反模式服務(wù)不可用，服務(wù)消費者會在毫秒級的時間內(nèi)得到通知，它可以返回錯誤信

3、息或者嘗試連接。但是如果服務(wù)接收了請求但是不響應(yīng)，服務(wù)消費者該怎么辦？可以無限等待或者設(shè)置一個超時時間三、使用熔斷器設(shè)計模式這種設(shè)計模式就像家里的電器的保險絲一樣，當(dāng)負(fù)載過大，或者電路發(fā)生故障或異常時，電流會不斷升高，為防止升高的電流有可能損壞電路中的某些重要器件或貴重器件，燒毀電路甚至造成火災(zāi)。保險絲會在電流異常升高到一定的高度和熱度的時候，自身熔斷切斷電流，從而起到保護電路安全運行的作用。四、共享反模式微服務(wù)的目標(biāo)之一就是盡量少的共享，這會幫助微服務(wù)確定它的有界上下文，服務(wù)更容易的測試和部署。服務(wù)之間依賴越多，服務(wù)則更難被隔離。不要把所有共享的代碼放在一個庫中，比如 common.jar

4、,而是根據(jù)它們的邏輯劃分成更小的庫，比如 security.jar , persistence.jar , dateutils.jar五、到達(dá)報告反模式數(shù)據(jù)庫的非獨立性影響微服務(wù)的性能，尤其是復(fù)雜報告的查詢批處理程序成批地將微服務(wù)的數(shù)據(jù)倒入到報告的數(shù)據(jù)庫中，但是問題和HTTP pull model一樣，這會帶來數(shù)據(jù)庫的非獨立性，微服務(wù)數(shù)據(jù)庫格式的改變也會影響報告服務(wù)五、到達(dá)報告反模式Event-based push model，也叫 data pump。雖然相對復(fù)雜，但是不會違背微服務(wù)的原則。六、沙粒陷阱采用微服務(wù)架構(gòu)的時候最大的挑戰(zhàn)之一就是服務(wù)粒度的問題。微服務(wù)的服務(wù)粒度多大合適？服務(wù)粒度至

5、關(guān)重要，它會影響應(yīng)用的性能、健壯性、可靠性、可測性、設(shè)置發(fā)布模型。當(dāng)服務(wù)的粒度太小的時候就會遇到沙粒陷阱。微服務(wù)的微并不意味著服務(wù)越小越好，但是多小是??？六、沙粒陷阱分析服務(wù)編排服務(wù)的范圍和功能分析數(shù)據(jù)庫事務(wù)七、無因的開發(fā)者陷阱沒有考慮tradeoff。發(fā)布、改變控制、測試都深受影響。八、隨大流陷阱微服務(wù)是現(xiàn)在的潮流，所以你選擇了微服務(wù)，還沒有仔細(xì)的分析你的商業(yè)需求、商業(yè)驅(qū)動、組織架構(gòu)和技術(shù)環(huán)境，這就是隨大流陷阱。微服務(wù)并不適合所有的場景。避免這個陷阱的方式充分理解微服務(wù)的好處和短處，俗話說，知己知彼，百戰(zhàn)不殆。好處：發(fā)布：易于發(fā)布測試：易于測試改變控制：更容易的改變一個服務(wù)的功能模塊-規(guī)?？?/p>

6、擴展短處Team組織改變性能可靠性降低運維難度加大九、靜態(tài)契約陷阱要為你的服務(wù)設(shè)計版本號。有兩種實現(xiàn)方式，在header中加入版本號，或者在服務(wù)的schema中加入版本號。十、我們到了嗎這個陷阱發(fā)生在你不知道遠(yuǎn)程調(diào)用要花多長時間的情況。50秒？平均多長時間呢，長尾的延遲呢？首先你應(yīng)該測量服務(wù)的調(diào)用時間，至少能知道一個服務(wù)遠(yuǎn)程調(diào)用的大概時間。然后你應(yīng)該評估不同的服務(wù)通訊協(xié)議的性能，比如REST、JMS、AMQP等。當(dāng)然性能也不是唯一個衡量遠(yuǎn)程通訊協(xié)議的因素。十一、REST陷阱如果把REST作為唯一的通訊方式，就有可能掉入這個陷阱。比如如何處理異步通訊(http 1.1是blocking的)、如何

7、在一個事務(wù)中管理多次服務(wù)調(diào)用？如何支持廣播？你應(yīng)該考慮兩種類型的消息標(biāo)準(zhǔn)作為微服務(wù)架構(gòu)中的消息傳遞：特定平臺的標(biāo)準(zhǔn)和平臺無關(guān)的標(biāo)準(zhǔn)。特定平臺的標(biāo)準(zhǔn)比如 JMS for java、平臺無關(guān)的比如 AMQP。使用消息系統(tǒng)的好處可以異步請求，還可以實現(xiàn)廣播的方式，還可以實現(xiàn)事務(wù)請求。二、微服務(wù)的事務(wù)管理一、事務(wù)有四個基本要素：ACIDA（Atomicity，原子性）：整個事務(wù)中的所有操作，要么全部完成，要么全部失敗，不可能停滯在中間某個環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾（Rollback）到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。C（Consistency，一致性）：一個事務(wù)可以封裝

8、狀態(tài)改變（除非它是一個只讀的）。事務(wù)必須始終保持系統(tǒng)處于一致的狀態(tài)，不管在任何給定的時間并發(fā)事務(wù)有多少。I（Isolation，隔離性）：隔離狀態(tài)執(zhí)行事務(wù)，使它們好像是系統(tǒng)在給定時間內(nèi)執(zhí)行的唯一操作。如果有兩個事務(wù)，運行在相同的時間內(nèi)，執(zhí)行相同的功能，事務(wù)的隔離性將確保每一事務(wù)在系統(tǒng)中認(rèn)為只有該事務(wù)在使用系統(tǒng)。這種屬性有時稱為串行化，為了防止事務(wù)操作間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用于同一數(shù)據(jù)。D（Durability，持久性）：在事務(wù)完成以后，該事務(wù)對數(shù)據(jù)庫所作的更改便持久的保存在數(shù)據(jù)庫之中，并不會被回滾。傳統(tǒng)事務(wù)管理二、兩階段提交協(xié)議（2PC）應(yīng)用程序調(diào)用事務(wù)協(xié)調(diào)器中的提交方法事務(wù)協(xié)調(diào)器將聯(lián)絡(luò)事務(wù)中涉及的每個數(shù)據(jù)庫，并通知它們準(zhǔn)備提交事務(wù)（這是第一階段的開始）接收到準(zhǔn)備提交事務(wù)通