最近閱讀了一篇文章《小公司需要使用微服務架構嗎？》，這篇文章討論了微服務架構的優缺點，以及微服務架構是否適合小公司。爲了蹭一下熱度，本文將結合兩年半的練習經驗，談談我對這篇文章的讀後感。
原文摘要
New Bing 這樣總結到：
你的問題是請幫你總結一下這篇文章主體的內容。我從網上搜索了一些相關的信息，發現這篇文章的主要內容是：
這篇文章是關於小公司是否需要使用微服務架構的討論，作者分析了使用微服務的四大門派，分別是跟風派，技術派，業務派和架構派。
跟風派是指那些盲目追隨技術潮流，沒有自己的判斷和思考的人，他們認爲微服務是一種萬能的解決方案，可以提高開發效率，降低維護成本，提升系統性能和穩定性。
技術派是指那些喜歡嘗試新技術，追求技術創新，不懼怕技術挑戰的人，他們認爲微服務是一種技術趨勢，可以讓他們學習更多的技術知識，提升自己的技術水平，增加自己的市場競爭力。
業務派是指那些以業務需求爲導向，根據業務場景和規模選擇合適的技術方案的人，他們認爲微服務是一種業務架構，可以讓他們更好地解決業務問題，提供更好的用戶體驗，實現更快的業務迭代。
架構派是指那些有架構設計能力，能夠從整體和局部的角度考慮系統的可靠性，可擴展性，可維護性，可測試性等方面的人，他們認爲微服務是一種架構模式，可以讓他們更好地構建和管理複雜的系統，實現更高的系統質量。
作者認爲，小公司是否需要使用微服務架構，沒有一個固定的答案，需要根據自己的實際情況和目標來決定，不要盲目地跟風或者拒絕。作者建議，小公司在使用微服務架構之前，要考慮以下幾個方面 ：
- 微服務架構的優勢和劣勢，以及適用的場景和條件
- 微服務架構的實施成本和風險，以及應對的策略和措施
- 微服務架構的組織和管理方式，以及配套的技術和工具
- 微服務架構的演進路徑和目標，以及評估和改進的方法和指標
作者最後總結，微服務架構不是一種銀彈，也不是一種魔鬼，而是一種工具，需要根據自己的需求和能力來合理地使用。
歡迎關注作者的微信公衆號“newbe技術專欄”，獲取更多技術內容。
軟件工程本質上還是工程
工程可以被簡單概括爲在預期的時間內通過可控的成本達成預期的目標。 —— 正在掏下水道的良工
正如張工所說，工程問題本質就是時間、成本和目標之間進行平衡，最終以達成各方滿意的結果。而爲了實現這個一結果，軟件工程中引入了各種理論、方法、工具和技術。它們或者是縮短時間、或者是控制成本、或者是改善目標，都是圍繞這個核心目標展開的。
微服務本身作爲工程實踐中的一套理論和工具，也不能逃脫這個規律。爲此，在決定是否採用微服務的時候，只需要考慮微服務是否能夠幫助我們實現我們的目標，是否能夠幫助我們縮短時間、控制成本、改善目標，就可以了。
例如，微服務架構的引入會由於服務數量的增加，而導致部署運維的難度增加，對應的就是增加了時間和成本。因此，在微服務架構應用時，就需要配到對應的運維工具以及有運維能力的人員，來緩解這個問題。使得整個工程的時間、成本和目標之間達到平衡。
沒有充分了解就不具備評價問題的資格
既然要做決定，你就應該有自信說出：沒人比我更懂。🤗 —— 和領導一起上廁所的汪總
常有人說我不懂製冷，但我有權評價空調。不過現在的場景是要造空調，因此，我需要了解空調的原理，才能夠評價空調的設計是否合理。故而，如果要評價微服務架構是否合適，那麼就需要了解微服務架構的原理，才能夠評價微服務架構的設計是否合理。
作爲練習時長兩年半的工程師，我可以很有自信的說出：沒人比我更不懂微服務架構了。所以我也不具備評價微服務架構是否合適的資格。不過我覺得如果有那一天能夠決策是否採用微服務架構，那麼我應該做過下面這些事情：
- 瞭解微服務架構的原理，包括微服務架構的優勢和劣勢，以及適用的場景和條件。
- 掌握微服務架構的實施成本和風險，以及應對的策略和措施。
- 明白微服務架構的組織和管理方式，以及配套的技術和工具。
- 清楚公司的演進路徑和目標，以及評估和改進的方法和指標。
我覺得一般來說，可以使用如下大致格式來界定評價方式：
針對問題：支付系統和物流系統的耦合性太高，導致系統的可擴展性和可維護性很差，需要解耦。
爲何要解：公司業務發展迅速，需要接入更多的支付渠道和物流渠道，如果不解耦，系統將無法擴展。
解決方案：引入微服務架構，將支付系統和物流系統拆分爲獨立的服務。併成立兩個團隊，分別負責支付系統和物流系統的開發和運維。
引入成本：重構帶來的過渡時間。額外的硬件成本，額外的人員成本。
矛盾的普遍性和特殊性
如果不研究矛盾的特殊性，就無從確定一事物不同於他事物的特殊的本質，就無從發現事物運動發展的特殊的原因，或特殊的根據，也就無從辨別事物，無從區分科學研究的領域。 —— 《矛盾的普遍性和特殊性》
微服務作爲一套理論和工具，實質上是爲了解決軟件工程中存在的特殊矛盾而出現的。這個矛盾就是：軟件工程中的複雜性和變化性。
而實際上，幾乎任何引入到軟件工程的理論、方法、工具和技術都是爲了解決這一矛盾。因此也常有人說：軟件工程唯一不變的就是變化本身。
故而，假如換做是別的理論或者工具，實際上討論的方式都是相同的。例如：
- 是否應該引入容器化
- 是否應該採用某種編程語言
- 是否應該劃分一個新的部門
總結
原文作者內容清晰，表述完整，邏輯嚴謹，值得學習。
微服務架構作爲軟件工程中使用到的一套理論和工具，本質上是爲了解決軟件工程中存在的特殊矛盾而出現的。爲了能夠評估引入的合理性，我們需要了解微服務架構的原理，包括微服務架構的優勢和劣勢，以及適用的場景和條件。這樣的評價方式同樣也適用於軟件工程中使用到的其他理論、方法、工具和技術。
參考
感謝閱讀，如果覺得本文有用，不妨點擊推薦👍或者在評論區留下 Mark，讓更多的人可以看到。
歡迎關注作者的微信公衆號“newbe技術專欄”，獲取更多技術內容。
- 本文作者： newbe36524
- 本文鏈接： https://www.newbe.pro/Others/0x021-after-reading-Do-Small-Companies-Need-to-Use-Microservices-Architecture/
- 版權聲明： 本博客所有文章除特別聲明外，均採用 BY-NC-SA 許可協議。轉載請註明出處！
-
https://www.cnblogs.com/jiujuan/p/17116605.html↩