在 《微服務架構設計模式》 一書中，作者總結了關于微服務的一些“重點”，原文如下：

?中國企業和開發者對微服務架構的熱情讓我印象深刻。但如同我給所有客戶的忠告一樣，我想對本書的讀者說:
?
???第一，要記住微服務不是解決所有問題的萬能“銀彈”。
?
???第二，編寫整潔的代碼和使用自動化測試至關重要，因為這是現代軟件開發的基礎。
?
???第三，關注微服務的本質，即服務的分解和定義，而不是技術，如容器和其他工具。
?
???第四，確保你的服務松耦合，并且可以獨立開發、測試和部署，不要搞成分布式單體(DistributedMonolith)那將會是巨大的災難。
?
???第五也是最重要的，不能只是在技術上采用微服務架構。擁抱DevOps的原則和實踐.在組織結構上實現跨職能的自治團隊，這必不可少。
?
?還必須記住:實現微服務架構并不是你的目標。你的目標是加速大型復雜應用程序的開發。
?最后，我要感謝中國的所有客戶，讓我有機會與你們探討微服務。我還要感謝那些讓我能夠討論技術而不用學說中文(這可比微服務難多了)的同傳翻譯。我希望你會喜歡閱讀這本書，它會教你如何成功開發微服務。我期待著再次訪問中國，與我的讀者見面，幫助更多企業客戶實施微服務架構。
?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ?ChrisRichardson2019年2月13日

核心思想 第二 和 第五，總結為：微服務不只是技術問題， 也是團隊結構問題。

想要理解這句話，可以先了解下著名的康威定律：

康威第一定律

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967)

組織設計的產品/設計等價于這個組織的溝通結構。

用人話來說，就是你組織是啥德行，產品就是啥德行。從這個角度上來說，阿里的產品架構都非常嚴謹，中規中矩，先頂層設計，后逐步細化。所以釘釘能夠成功也來源于阿里本身的組織架構。

---

康威第二定律

There is never enough time to do something right, but there is always enough time to do it over。

時間再多一件事情也不可能做的完美，但總有時間做完一件事情。

這個定律在概念上就是“敏捷編程”，即持續集成持續部署持續交付，devops。

---

康威第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

線型系統和線型組織架構間有潛在的異質同態特性。

異質同態指的是系統和組織雖然是兩個東西，但是有相同的結構。所以系統是啥樣，組織也就得變成那個樣子。

比如公司如果是單體架構，那就只需要一個開發組即可；但是如果是前后端分離，那么必然就會拆分為前端組和后端組，分別進行管理。這就是所謂的異質同態。

如果系統和組織的結構不匹配，那么將會是災難。你想象一下系統是前后端分離，但是壓根就沒拆分前后端的崗位是啥情況？

---

康威第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。

大的系統組織總是比小系統更傾向于分解。

當系統功能越來越多，流量越來越大，垂直擴展無法解決這些問題。進而走向了水平擴展到道路，那么想要支持水平擴展，就需要解決很多基礎問題，比如會話狀態，比如lb等等。當你真的支持了水平擴展了，你自然而然就會發現，有些業務訪問量很大，需要的資源很多，但是有些很小，業務上也無需塞到到一個服務里面，這時你就會想到去拆分了。拆分后，你反而需要解決更多的問題。所以這一定律也就更考驗到服務拆分的能力。

---

綜上所述，關于微服務架構，本身是服務于系統架構而生，面向日漸復雜的系統架構。

1. 拆分微服務的目的應該為：性能伸縮， 運維獨立以及團隊結構優化。

2. 如果你想要為了讓團隊技術追新兒使用新的微服務技術，為技術而技術，大可不必，springboot 也很香。

3. 在大部分的系統架構升級中，往往會帶來更多的維護成本，架構一直都是一個取舍，為了解決伸縮性的問題，就要舍棄單體應用的簡單性，引入分布式的復雜性。往往 1+1 是 < 2的。

4. 實現“高內聚，低耦合”，說得容易，做得費勁。

總結

以上是生活随笔為你收集整理的系统架构升级要不要上微服务？历“久”弥新微服务——你真的需要升级微服务架构吗的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。