微服務 spring boot 譯<三> 微服務架構

時間 2019-12-06

原文原文鏈接

Design with the Domain in Mind

幾個世紀以來，模型一直被用來簡化和理解一個問題。例如，手機上的 GPS 地圖是步行或開車時導航城市的絕佳模型。這個模型對駕駛商用飛機的人來講是徹底無用的，由於他們使用的模型更適合描述路徑點、地標和急流。不一樣的模型或多或少都有意義，這取決於它們所處的上下文。EricEvans的開創性著做「領域驅動的設計」(Addison-Wesley，2004)幫助咱們爲複雜的業務流程構建模型，這些模型也能夠在軟件中實現。最終，軟件中真正的複雜性不是技術，而是模棱兩可的、循環的、矛盾的模型，這些模型是業務人員在頭腦中快速梳理出來的。給定一些上下文，人類能夠理解模型，可是計算機須要更多的幫助；這些模型和上下文必須融入軟件中。若是咱們可以實現與實現綁定的這個級別的建模(反之亦然)，那麼不管什麼時候業務發生變化，咱們均可以更清楚地瞭解軟件中的變化。咱們着手創建這些模型的過程和圍繞它的語言須要時間，而且須要快速的反饋循環。git

Evans提供的工具之一是識別和顯式分離不一樣的模型，並確保它們在各自的有限上下文中具備內聚性和無歧義性。github

有界上下文是一組域對象，它們實現了一個模型，該模型試圖簡化和傳遞業務、代碼和組織的一部分。例如，當咱們真正須要靈活性(聽起來熟悉嗎？)時，咱們在設計系統時努力提升效率。在一個簡單的自動部件應用程序中，咱們試圖爲整個域提供一個統一的「規範模型」，最終獲得像Part、Price和Address這樣的對象。若是庫存應用程序使用了「Part」對象，那麼它將引用一種類型的部件，好比「剎車」或「輪」。在汽車質量保證系統中，部件多是指具備序列號和惟一標識符的很是特定的部件，用於跟蹤某些質量測試結果等等。咱們努力嘗試有效地重用相同的規範模型，可是庫存跟蹤和質量保證問題是使用部件對象的不一樣業務關注點，語義不一樣。對於有界上下文，一個部件將被顯式建模爲PartType，並在該上下文中被理解爲表示「Part類型」，而不是部件的特定實例。有了兩個獨立的有界上下文，這些部件對象能夠在它們本身的模型中一致地演化，而不須要以奇怪的方式相互依賴，所以咱們已經達到了必定程度的敏捷性或靈活性。web

這種對領域的深入理解須要時間。可能須要幾回迭代才能徹底理解業務模型中存在的模糊性，並正確地將它們分離出來，並容許它們獨立地進行更改。這至少是建立微服務很困難的一個緣由。分割一塊巨石不是一件容易的事，可是不少概念已經被融入其中，你的工做就是識別和雕刻它。對於一個綠地項目，除非你深入理解它，不然你什麼也不能作。事實上，咱們聽到的全部微服務成功的故事(好比亞馬遜和網飛)在成功過渡到微服務以前都是沿着巨石的道路開始的。shell

Design with Promises in Mind

在具備自主團隊和服務的微服務環境中，記住服務提供者和服務消費者之間的關係是很是重要的。做爲一個自主的服務團隊，您不能將義務放在其餘團隊和服務上，由於您並不擁有它們；根據定義，它們是自治的。你所能作的就是選擇是否接受他們對功能或行爲的約定。做爲向他人提供服務的人，您所能作的就是向他們約定某種行爲。他們能夠自由地信任你或不信任你。約定理論是馬克·伯吉斯在2004首次提出的一種模式，他在「尋找肯定性」(O‘Reilly，2015)一書中對此進行了闡述，是對自治系統的研究，包括人、計算機和相互提供服務的組織。數據庫

就分佈式系統而言，約定有助於闡明服務可能提供的內容，並明確哪些能夠作，哪些不能作。例如，咱們的團隊擁有圖書推薦服務，咱們承諾爲您可能詢問的特定用戶提供一套個性化的圖書推薦服務。當您調用咱們的服務，而咱們的後端(存儲該用戶當前的推薦視圖的數據庫)不可用時，會發生什麼狀況？咱們能夠拋出異常和堆棧跟蹤，但這不是一個很好的經驗，並可能炸燬系統的其餘部分。由於咱們作出了承諾，因此咱們能夠盡一切努力來實現它，包括返回一個默認的圖書列表，或者每本書的子集。有時，承諾沒法兌現，而肯定最佳行動方案應由咱們但願爲咱們的用戶提供的預期經驗或結果來驅動。這裏的關鍵是咱們的服務有責任努力履行其承諾(返回一些建議)，即便咱們的依賴服務不能保持它們的服務(數據庫已關閉)。在努力履行承諾的過程當中，對系統的其餘部分和咱們正在努力維護的服務質量是有幫助的。後端

Distributed Systems Management

說到底，管理一個單一的系統比管理一個分佈式系統要容易得多。若是隻有一臺機器和一個應用程序服務器，而且系統有問題，咱們知道去哪裏找。若是您須要進行配置更改，升級到特定的版本，或者保護它，那麼它仍然位於一個物理和邏輯位置。管理、調試和更改它更容易。對於某些用例，單一系統可能有效；可是對於須要規模的用例，咱們能夠考慮利用微服務。正如咱們前面所討論的，微服務並非免費的；爲了得到靈活性和可伸縮性，必須管理一個複雜的系統。安全

關於微服務部署的可管理性的一些簡單問題：bash

• 咱們如何啓動和中止服務隊？服務器

• 咱們如何聚合跨微服務的日誌/度量/SLA？負載均衡

• 咱們如何在彈性環境中發現服務？

• 負載均衡？

• 咱們怎麼知道集羣的健康或者單個服務的健康？

• 在服務倒下的時候，咱們如何重啓咱們的服務？

• 咱們如何進行細粒度的API路由？

• 咱們如何確保咱們的服務安全？

• 若是集羣忽然崩潰或發生意外行爲，咱們如何節流或斷開其部分？

• 咱們如何部署一個服務的多個版本並適當地路由到它們？

• 咱們如何在一大羣服務中進行配置更改？

• 咱們如何以安全、可審計、可重複的方式對應用程序代碼和配置進行更改？

這些都不是容易解決的問題。本書的其他部分將致力於讓Java開發人員使用微服務啓動和運行，並可以解決列出的一些問題。完整的，完整的清單，如何爲前面的問題(和許多其餘)解決的在第二版這本書。

Technology Solutions

在本書的其他部分，咱們將向您介紹一些流行的技術組件，以及它們如何幫助解決使用微服務體系結構開發和交付軟件的一些問題。如前所述，微型服務不只僅是一個技術問題，創建正確的組織結構和團隊以促進微型服務相當重要。從SOAP切換到REST還並不構成微服務體系結構。

對於建立微服務的Java開發團隊來講，第一步是讓一些東西在他們的機器上本地工做！本書將向您介紹三種使用微服務的還比較好的Java框架：SpringBoot、DropWizard 和 WildFlySwarn。每一個框架對於不一樣的團隊、組織和微服務方法都有好處。正如技術的標準同樣，有些工具更適合於工做或團隊使用它們。這些並非惟一可使用的框架。有一對框架 Vert.x 和 Lagom 對微服務採起了響應式的方法。使用基於事件的模型進行開發的思惟模式有些不一樣，須要一個不一樣的學習曲線，所以在本書中，咱們將堅持使用一個大多數企業Java開發人員都會感到溫馨的模型。
本書的目標是幫助您掌握每一個框架的基礎知識。在最後一章中，咱們將深刻探討一些高級概念，可是對於每一個框架的第一步，咱們將假設一個hello-world微服務應用程序。這本書並非開發微服務的全面參考資料；每一節都會給您留下參考資料的連接，以便根據須要進行更多的探索。咱們將經過建立多個服務迭代hello-world應用程序，並展現一些簡單的交互模式。

每一個框架的最後一次迭代將研究諸如分隔和承諾理論之類的概念，以使咱們的服務在面對錯誤時具備彈性。咱們將深刻研究NetflixOSS堆棧的某些部分，如hystrix，這些部分可使咱們更容易地實現此功能。咱們將討論這種方法的優缺點，並探討存在哪些其餘選擇。

在咱們瀏覽這些示例時，咱們還將討論Linux容器爲微服務的部署、管理和隔離以及本地開發帶來的價值。Docker和Kubernetes爲大規模地處理分佈式系統帶來了豐富的簡化，所以咱們將討論有關容器和微服務的一些良好實踐。

在本書的最後一節中，咱們將爲您提供一些關於分佈式配置、日誌記錄、度量和持續交互的想法。