首先，來自Darren的消息是，微服務架構並不是構建大規模企業應用程序的新方式。 Netflix和亞馬遜等公司已經實施了微服務架構，在過去幾年中提供了成功的產品。
但是微服務架構適合您的組織嗎？答案不是簡單的是或否，但我會嘗試用Darren的講話作為指導來引導你找到答案。
微服務架構是一個將在多個方面影響您的組織的旅程 - 在文化，技術和運營方面。讓我們考慮一個跨國企業的單體應用程序，該應用程序已經成熟多年並佔據了市場主導地位。從軟件工程師或架構師的角度來看，簡化代碼庫的複雜區域以使其更易於維護是一種很好的做法。
那麼當你遇到一個瘋狂的大型Java類時，你會怎麼做，這些Java類包含許多代碼行和一個不幸的方法，佔40％的類？一個自然（和明智）的事情是與團隊進行某種形式的討論，並提出一種策略，將類分解為多個較小的類和/或方法。現在問問自己為什麼清理整體Java類很重要？
如果您的答案是更簡單的單元測試，更容易進行代碼審查，更改影響，那麼我建議您將相同的思維過程應用於構成產品的整體服務和模塊。
將monolith應用程序拆分為更小，可管理的服務有幾個原因。如果您是組織中的業務負責人，以下可能是您的一些擔憂：
- 進入新市場
- 支持創新
- 在業務功能和系統之間創建更好的一致性
- 改變治理結構以更好地支持快速決策
- 快速響應新的市場條件
- 抵禦市場顛覆者
作為首席技術官或首席架構師，您有責任評估最能解決上述問題的不同解決方案，並設計符合組織願景的系統。以下是在考慮微服務架構時需要關注的一些關鍵領域：
- 多種服務之間的依賴關係管理
- 端到端功能測試的大小
- 快速檢測故障，正常故障並快速恢復
- 容器作為構建工件
- 跨組織邊界重用組件/模塊
- 公共使用服務的API合同
- 監控部署生命週期的各個階段
- 集中式架構團隊與分散式架構團隊
- 基建自動化
架構師的角色隨著微服務的採用而發展，並委託他或她承擔挑戰性的責任，從而形成架構治理。架構治理是組織嘗試開始微服務之旅的關鍵因素之一，因為如果沒有正確的順序，該過程將很快導致微管理而不是微服務。
將monolith分成多個可管理服務的最大優勢之一是使一個小團隊能夠全面管理其服務的生命週期 - 開發，測試和推向生產。這意味著企業架構師不再需要承擔單個服務的內部工作負擔，而是高度關注整個系統中服務之間的交互。此外，架構師應密切關注系統的整體運行狀況，以確保每項服務以一致的方式生成與監控相關的指標。
為開發團隊提供完全的權限，以便在構建服務時選擇他們選擇的技術堆棧並不意味著架構師不再對其實現有任何發言權。事實上，架構師受到高度鼓勵，可以教育和影響開發團隊。例如，考慮到服務必須處理的數據的高度非結構化特性，架構師可以建議使用NoSQL數據庫而不是關係數據庫。例如，Netflix將JVM的使用標準化為一個平臺，以便他們可以跨服務使用標準庫。
雖然架構師之一忙於與開發團隊合作，但另一個人正在與“業務”團隊合作，以使技術願景與業務願景保持一致。這對於建築師來說是一個重要特徵，因為系統需要能夠適應產品願景或用戶反饋的變化。因此，架構師需要始終掌握行業中的最新趨勢，工具和框架，並準備好為給定的工作應用正確的工具。
Darren談到了“部署耦合”的概念，強調了許多單片系統和傳統企業架構需要在單個版本中將所有系統的更改同步到生產中這一事實。這反過來導致長時間運行的測試周期從未捕獲任何東西，並且感覺沒有人可以失敗，因為一個系統未達到其截止日期意味著其他所有人都被推出。
通過使用遠程調用作為集成服務的機制，可以避免部署耦合。微服務社區建議使用REST over HTTP而不是其他遠程通信協議（如RPC或SOAP），因為基於非HTTP的協議往往會將您綁定到特定平臺或對互操作性施加限制。通過基於用戶級合同使用HTTP集成服務，開發團隊可以避免永無止境的端到端測試階段的陷阱並保持合適的速度。
然而，管理數百個服務會使組織的操作複雜化。作為一個組織，您必須確保擁有可靠的DevOps基礎架構，以便處理應用程序監視和警報。正如我上面提到的，架構師必須至少標準化服務發出日誌的方式，以便運營團隊可以監控整體系統運行狀況，並且如果需要進一步調查，則能夠深入到服務級別監控。
最後，每個組織都必須努力招募，培訓和留住高素質的技術人員，因為“微觀團隊”之間的溝通和協作需要有效，技術上的刺激以及最重要的樂趣是至關重要的！
我希望這可以解決你對大型企業中微服務架構的一些擔憂。我鼓勵你觀看這個非常有見地的視頻錄製，其中Darren更詳細地討論了這些非常關注的問題。如果您正在尋找有關微服務架構的其他材料，請查看Martin Fowler的文章或ThoughtWorks網站上的其他微服務洞察博客。
閱讀更多 智能時刻 的文章
