我最喜歡博客（而且從來沒有得到足夠的）的一件事就是反饋。我之前發表的文章“雕刻它 - 微服務，巨石和康威定律”，產生了一些評論/討論，這些評論/討論合在一起，保證了一個後續帖子。
其中一個討論是與Ruth Malan和Jeff Sussna就治理進行的Twitter交流。傑夫認為分權治理的概念是“有爭議的”，儘管他認為集權治理是“有問題的”和“僵化”。露絲觀察到“或者至少是一個權衡軸和（組織）設計......？ （甚至“聯邦”也有廣泛的解釋）“。我為一些集中治理的需要辯護，但是剋制，注意“管理比必要更深的會導致問題，例如：問題是BDUF（IMO）是B，而不是UF“。
當應用程序跨越多個團隊，所有團隊都獨立部署時，將需要一些集中式治理。關鍵是制定道路規則，允許團隊獨立工作而不會相互干擾，不會嘗試微觀管理。這種編排需求不僅僅侷限於技術方面。正如Tom Cagley在我上一篇文章中的評論所指出的那樣“在考慮跨團隊和組織邊界的流程改進時，也可以利用你的論點”。團隊之間衝突的流程模型很容易使分佈式解決方案複雜化。
另一篇關於“雕刻它 - 微服務，巨石和康威定律”的評論，這一次來自Robert Tanenbaum，討論了重用，並質疑圖書館在某些情況下是否是更好的選擇。 Robert還觀察到“敏捷原則告訴我們實現滿足需求的最小體系結構，只有在需求超出最小實現時才能使用更復雜的體系結構”。我認為微服務和SOA架構更像是一種分區機制而不是重用工具。因為重複使用會帶來更多的成本和負擔，而不是大多數人認為，我傾向於不那麼熱衷於這方面。但是，我絕對同意，分佈式架構可能更適合於演進過程的後續步驟，而不是起點。來自Chris Richardson的“微服務：分解應用程序的可部署性和可伸縮性”的引用很好地說明了（重點是我的）：
使用微服務架構的另一個挑戰是決定在應用程序生命週期的哪個階段應該使用這種架構。 在開發應用程序的第一個版本時，您通常不會遇到此體系結構解決的問題。 此外，使用精心設計的分佈式架構將減緩開發速度。
Michael Brunton-Spall的“什麼是微服務及其重要性”為這種架構風格所涉及的權衡性質提供了更多背景：
微服務交易複雜的單塊，用於簡單服務的複雜交互系統。
一個巨大的整體可能是如此複雜，以至於很難對某些行為進行推理，但在技術上可以推理它。相互交互的簡單服務將表現出緊急行為，而這些行為是不可能完全推理的。
對於複雜系統而言，級聯故障更是一個問題，一個簡單系統中的故障會導致其他系統出現故障。幸運的是，有一些模式，例如背壓，死人的開關等等，可以幫助你減輕這種情況，但你需要考慮這一點。
最後，即使問題發生變化，微服務也可以成為解決問題的解決方案。因此，一旦構建，如果您的需求發生變化以使您的有界上下文調整，正確的解決方案可能是拋出兩個當前服務並創建三個來替換它們，但通常更容易簡單地嘗試修改其中一個或兩個。這意味著微服務可以很容易地在較小的情況下進行更改，但需要更多的監督才能在大的情況下進行更改。
引號中“複雜(complicated)”和“複雜(complex)”之間的區別尤為重要。所提到的緊急行為意味著複雜系統的行為只能在回顧中完全解釋。這意味著分佈式應用程序不能被視為具有部件之間空間的整體件，但必須根據其性質進行設計。這是Jeppe Cramon的一個主要主題，他在TigerTeam網站上圍繞微服務的持續工作非常值得一讀。
Jeppe在我的帖子的LinkedIn討論中發表了一對評論。在那次討論中，Jeppe指出，專注於業務能力的小型服務比整體服務更可取，但這與將幾個巨型網絡與Web服務連接起來並不相同。然而，主要關注的是服務“擁有”的數據的性質。我在上一篇文章中非常簡短地提到了這一點，並提到需要權威性的一些概念（中央治理）。 Jeppe表示贊同，並指出整體結構導致多主數據架構，其中多個系統在同一實體上包含冗餘的，可能相互衝突的數據。
底線？在我看來，這種架構風格具有增強企業運營的巨大潛力，前提是它沒有過度營銷（“SOA治癒禿頭，腸易激綜合症，促進世界和平......免費!!!”）。服務並不是將遺留系統毫不費力地轉變為二十二世紀技術的秘訣。有一些警告，權衡和成本。一種務實的方法，考慮到這些以及潛在的好處，應該比昨天的“如果建立它和他就會來”的哲學更有可能取得成功。
閱讀更多 智能時刻 的文章
