元旦贈書活動還在繼續中，歡迎點選下方連結參與：

如果在諸多熱門雲端計算技術中，諸如容器、微服務、DevOps等，找出一個最火的方向，那麼非微服務莫屬。在小數推薦的這篇文章裡，做與不做微服務好像理由都很充分。另外，誕生幾十年的康威定律，在組織結構調整和變革方面，依然神采奕奕。

建立一種新的軟體專案架構，來封裝離散服務，對於全新的專案來說，這是非常簡單的。但是，對於大多數軟體開發者來說，誰又有大把的奢侈時間一直用在全新專案上呢？

大多數軟體開發人員職責更多是維護或增加現有軟體系統的功能。但是，如果問開發人員究竟是願意構建全新的專案，還是維護一個現有的系統，那麼支援新專案的呼聲肯定會成為壓倒性的聲音。事實上，希望與新技術或新專案合作也是開發人員離職的原因之一。為什麼呢？

1. 識別問題容易，但修復很難

維護現有系統時，很容易識別架構的問題。為什麼？因為基於良好的架構，系統很容易調整。

當需要去調整一個沒有設計封裝波動的已有系統時，架構的弱點就不言自明。即使是最小的表層變化也會給整個系統的其他部分帶來複雜的漣漪：新的依賴看似要無止境地延續下去，通過臃腫的方法簽名獲得更多的引數，自動化測試的規模和複雜性爆炸，同時降低了實際效用。

這些問題是不是聽起來很熟悉？你企業的架構是這樣的嗎？

如果答案是肯定的，那麼你有一個單體架構。單體架構是大多數軟體開發者遇到的最常見架構。

這個單體架構來自那些根本沒有設計封裝波動的系統，但是隨著業務需求和時間的推移，變得越來越複雜。

那麼用單體架構做什麼呢？

每個人在單體架構中工作時都會感到痛苦，開發和業務人員也是如此。開發者討厭臃腫的單體架構，因為開發的難度會隨著新開發動作的增加而增加。一旦單體架構達到臨界值，如何改變會成為一個真正可怕的命題。這會導致生產力和團隊士氣下降，業務受到影響。企業需要快速行動，單體架構卻會隨著時間的推移而變得越來越慢。

許多開發人員都希望把已有的架構丟掉，重新開始，但是這種想法無法和業務一起成長。“最好的軟體是目前就讓企業賺錢的軟體，無論設想中的新版本多麼偉大！”

所以新的計劃不能完全拋棄舊有的單體架構，業務要繼續，但不會再增加單體架構的複雜度。

微服務？

微服務是一個流行的詞彙，它模糊地表達了一個面向服務的架構，其中包含許多小的離散服務。

從表面上看，微服務似乎是單體架構的對立面（每個人都討厭單體架構），許多微服務通過提出新的特性請求，並以獨立服務的形式出現。這裡的問題是：當單體架構封裝所有系統的波動性，解耦的獨立服務並不能使企業免於任何波動。

以下是用微服務實現單個功能架構，它大概像這個樣子：

單體應用變得小了一點，新功能清晰地從系統的其餘部分解耦。這很好嗎？

當下一個功能請求進入時會發生什麼？

有兩個功能，我們已經看到一個問題。第二個功能建立在第一個功能之上，所以不能完全隔離。

如果隨著功能請求的進入，簡單地建立新的微服務，而不是封裝整個波動區域：

有改善嗎？來看看原始單體應用旁邊的微服務：

如果仔細觀察，會發現，所有服務依賴線模糊在一起，這只是發明了一個更復雜的單體架構。

小小的改變在整個系統中仍然會帶來複雜的漣漪。整個系統的行為改變將涉及到改變多個微服務。所有相同的問題再次出現，甚至可能更糟糕，這加劇了依賴關係難以追蹤的事實，而且，精心策劃的多服務部署比龐大的單體應用更加可怕。

什麼地方出了錯？

問題源於微服務本身不是架構。微服務就是一個簡單的詞，描述了作為獨立服務執行的系統，而不是一個單體應用。軟體架構的實際實踐包括仔細規劃，在哪裡劃分離散服務之間的界限，從而包含波動區域。當簡單地拿出一個單體應用，作為獨立服務來實施時，就沒有必要來考慮整個系統的封裝波動。

把系統看作一個整體，才能談架構

因此，如果單體應用，功能驅動的微服務太小，該怎麼做應對？

要知道想去的方向

要像從頭開始建立一樣，為整個系統設計理想的架構。

企業不能一下子從一個單體架構直接進入微服務架構，但是如果第一次啟動的時候，不清楚想達成的方向，那麼永遠也不會到達那裡。

給所有希望拆分現有單體應用的軟體開發者提供一些建議，但實際情況是這個路線圖對於每個系統都是獨一無二的。

Tips

• 如果只是設計新的功能而忽略已有的單體應用，則無法創建出色的架構；

• 如果不考慮整個系統，單體應用就不能有效分解；

• 微服務只是一個流行詞。更小並不總是更好。精心拆分服務邊界很重要；

2. 微服務與團隊：康威定律

微服務架構是獨特的，隨著時間的推移仍然保持靈活性，在一個專案的組織架構中時時發生影響 。對於大多公司而言，這非常具有挑戰性，因為它要求企業重新考慮組織模式。當準備開始微服務架構時，可以先問自己：“企業的組織能力是什麼？“在早期，先決條件應該是預先準備會遇到的困難，並思考應對之策。

微服務與康威定律：企業需要與團隊協同的架構

當涉及到組織團隊和微服務，著名的康威定律經常被提到。這項定律，越來越被廣泛地接受。

這一定律的缺陷在於，它更多是一種社會學規律，而不是純粹的科學規律，事實上，它總是以實證、例項的方式，而不是純粹的科學邏輯來論證。一般來說，社會學的結果很難證明，因為這些論證很大程度上基於假想中的思考和概念，只能通過更多的例項來加以驗證。

“組織的系統設計…往往受限於組織架構的產品設計和通訊的副本。”從這個規律，可以得出一些簡單的結論：

• 如果想要特定的結構，需要一個與組織團隊協同的架構。

• 如果經常改變架構，組織團隊也需要經常修改。

這兩個斷言，對於康威定律的原則，有著深遠的影響。首先是一個企業的適應能力，避免了野心家的傾向，對變革的抵制等等，也引發了機器取代人力的哲學思考。

基於以上結論，要上微服務架構的第一個問題是：“組織團隊如何適應這種架構?” Netflix 和亞馬遜的情況，當然是很正向的，但是否你的企業是否準備好了？其中重要的是，挖掘技巧和發現問題時的“剎車”措施來規避風險。

其中的技巧能迅速提升團隊的能力。在建立一個功能時，負責功能實現的團隊彙集了很多不同的技巧。當架構進入微服務模式時，將出現更多的協調性需求。

另一個竅門是開源技術的治理模式。開源專案由於其分散的結構，使它能夠建立高度鬆耦合的軟體，這是微服務架構的優點之一。它因此成為與其他團隊的協作方式，並推動具有程式碼能力的小團隊，在程式碼中實現變化。

但是，這個邏輯和組織變革在公司的接受度如何？這些技巧是否足夠在全公司範圍內協調、積累經驗和知識？分散的組織構建鬆耦合的程式碼，但技術或功能性的知識和技能不可能極端的解耦。否則，這就像拆東牆補西牆，是在用拆掉的牆來構建鬆耦合的架構。

真正的僵局會出現在文化和管理風格上，這點在最近幾年有了好轉。

一個比較好的例子是Spotify的框架（雖然我們應該限制自己使用meta frameworks，原因不再贅述）。Spotify採用通過使用開源元件來架構功能和治理，使用這些工具在一定規模下實現了靈活性矩陣模型。矩陣式組織必須確保知曉不同人具備的知識或技能。

最近流行的新管理方法已初見影響，特別是在那些尋求實現微服務的團隊組織中。

Holacracy管理模式：滿足業務模式前提下，完成微服務最佳實踐

上面談到了企業文化、主體、和變革的阻力。第一種型別的管理，來源於 Holacracy 管理模式。

Holacracy分為自治和獨立，並連結比自己更高的實體。這些圈子以閉環的形式，可以互相重疊，具有自組織而被上層管理的特殊性。每個圈子對於性質和組成的變化非常敏感。

可以想象，例如，底層圈子是微服務的開發隊伍，而上一層是架構和產品負責人，最頂端是應用的客戶業務線。這將讓產品和架構負責人要能在滿足業務需求的前提下，才能保證架構的最佳實踐。

這種架構方式也是開發者、軟體架構師的典型方式。所有可能來自不同或重疊的圈子組織。建立這種型別的組織是為了提高知識傳輸和構建架構的時間效率。

我們可能會認為，這種管理比較符合傳統的層級組織。事實上，即使層次是扁平的，它仍然存在，可以限制其專案團隊。總之，最好的方式就是簡化人與人之間的連結。

本文轉載自公眾號：數人云

原文連結： 1、Microservices and monoliths: getting service-oriented architectures just right https://www.tuicool.com/articles/VBzUFfJ 2、Executive Insights on the Current and Future State of Microservices https://www.tuicool.com/articles/RfuAJn2

推薦閱讀

長按指紋

一鍵關注

點選 “閱讀原文” 看看本號其他精彩內容