很長一段時間以來，我一直想寫一篇關於微服務架構主題的文章，但有兩件事一直阻止著我——我越深入這個主題，我就越覺得我知道的東西是顯而易見的，而我不知道的東西卻越來越多。不知道需要研究和研究。 另一方面，我認為廣大觀眾已經有了一些可以討論的東西。 因此歡迎其他意見。
康威定律與業務、組織和資訊系統之間的關係
我將再次引用：
“任何設計系統（廣義上）的組織都會收到一個其結構複製該組織中團隊結構的設計。”
——梅爾文‧康威，1967 年
在我看來，這條法則更可能與組織企業的可行性有關，而不是直接與資訊系統有關。 讓我用一個例子來解釋。 假設我們有一個相當穩定的商業機會，其生命週期如此之長，以至於組織一個企業是有意義的（這不是打字錯誤，但我真的很喜歡我偷來的這個術語）。當然，這個企業的支撐系統將在組織上和流程上對應此業務。
資訊系統業務導向
讓我用一個例子來解釋。 假設有一個組織銷售披薩業務的商機。 在 V1 版本中（我們稱之為預資訊），該公司是一家比薩店、一家收銀機和一家送貨服務公司。 此版本在環境變化較小的條件下可以長期存在。 然後版本 2 取代了它 - 更先進，能夠使用資訊系統作為其核心，透過整體架構進行業務。 在我看來，這裡對巨石來說簡直是一種可怕的不公義—— 據稱單體架構與領域業務模型不對應。 是的，如果真是這樣，該系統將根本無法運作——這與康威定律和常識相矛盾。 不，單體架構完全符合業務發展現階段的業務模型——當然，我指的是系統已經創建並投入運作的階段。 一個絕對美妙的事實是，無論採用哪種架構方法，服務導向的架構版本 3 和微服務架構版本 N 都將同樣運作良好。 有什麼問題嗎？
一切都在流動，一切都在變化，或者微服務是對抗複雜性的手段嗎？
在繼續之前，讓我們先來看看關於微服務架構的一些誤解。
使用微服務方法的支持者經常認為，將整體分解為微服務可以透過減少單一服務的程式碼庫來簡化開發方法。 在我看來，這種說法完全是無稽之談。 說真的，單體和同構程式碼中明顯的互動看起來很複雜？ 如果情況確實如此，那麼所有專案最初都將建構為微服務，而實踐表明從整體遷移到微服務更為常見。 複雜性並沒有消失；它只是從單一模組轉移到介面（資料匯流排、RPC、API 和其他協定）和編排系統。 而這很難！
使用異質堆疊的優勢也值得懷疑。 我不會說這也是可能的，但實際上它很少發生（展望未來 - 這應該發生 - 但作為結果而不是優勢）。
產品生命週期與服務生命週期
再看一下上圖。 我注意到業務的單獨版本的生命週期正在縮短，這並非巧合 - 在現代條件下，加速業務在版本之間的轉換對於其成功至關重要。 產品的成功取決於測試其業務假設的速度。 在我看來，這就是微服務架構的關鍵優勢。 但我們還是按順序來吧。
讓我們進入資訊系統演進的下一個階段—服務導向的SOA 架構。 因此，在某些時候我們在產品中強調了 長期服務 - 長期存在，即當在產品版本之間移動時，服務的生命週期有可能比產品的下一版本的生命週期長。 根本不改變它們是合乎邏輯的——我們 重要的是過渡到下一個版本的速度。 但遺憾的是，我們被迫不斷地對服務做出改變——這裡一切都適合我們，DevOps 實踐、容器化等等——所有想到的東西。 但這些仍然不是微服務！
微服務作為應對複雜性的手段......配置管理
在這裡，我們終於可以繼續討論微服務的定義角色 - 這是一種簡化產品配置管理的方法。 更詳細地說，每個微服務的功能根據領域模型準確地描述了產品內部的業務功能 - 這些東西不是存在於短暫的版本中，而是存在於長期的業務機會中。 並且向產品的下一版本的過渡實際上是在不被注意的情況下發生的- 您更改/添加了一個微服務，也許只是它們的交互方案，然後突然您發現自己處於未來，留下了不斷在不同版本之間跳轉的哭泣的競爭對手他們的巨石。 現在想像一下，有相當大量的具有預定義介面和業務功能的微服務。 您可以透過現成的微服務建立產品的結構 - 例如，只需繪製圖表即可。 恭喜你——你有了一個平台——現在你可以為自己吸引業務了。 夢想夢想。
發現
- 系統的架構應該由其組件的生命週期來決定。 如果元件存在於產品版本中，則透過使用微服務方法來增加系統的複雜性是沒有意義的。
- 微服務架構應該基於領域模型—因為業務機會是最長壽的領域
- 交付實踐（DevOps 實踐）和編排對於微服務架構來說是最重要的之一 - 因為組件變更率的增加對交付的速度和品質提出了更高的要求
來源： www.habr.com