一、使用微服務的四大門派
2.1、跟風派
技術大環境分析，到目前為止（2023.02）技術大環境：
- 各大公司都在宣傳微服務以及自家實踐情況
- 各種技術媒體也釋出很多關於微服務的文章
- 和別人討論技術相關的架構時，必然會提到微服務架構
這樣的氛圍下，微服務這 3 個字時不時的出現在眼前，加深你對它的印象。有時會給人帶來一種“幻覺”，如果自家公司技術不進行微服務的升級改造，技術就會落後於它們，對技術產生焦慮感。
這種屬於“跟風派”。完全沒有考慮自家業務發展情況，反正別家公司都是這麼做的，我也要這麼做。
2.2、追新派
有的技術人，在出現新的技術時，都想要在自家業務上對新技術實踐一番，以此體驗新的技術給他們帶來的一種“技術快感”。
“我使用了 NB 的技術”。為了技術而技術。
我意思不是說，對新技術不追求。
對於個人而言，這是一種“活到老，學到老”的積極學習態度，是值得大加提倡。
對於公司而言，需要考慮的情況比較複雜，至少有以下 3 點：
- 新技術出現的相關背景
- 新技術有哪些特性
- 公司現階段業務有哪些問題？新技術真的能解決這些問題嗎？
這種喜歡新技術的人，可以做公司技術預研，為將來遇到合適的業務應用這種技術打好基礎。
2.3、簡歷派
好多招聘 java 開發的，都寫著一個技能要求，熟悉 springcloud 並使用。
springcloud 是 java 語言的一個微服務開發技術棧大整合框架。
招聘，這也導致一些人嘗試使用微服務架構，為一下次跳槽做好準備。
這種情況於個人是一種驅動力，於公司則需要三思而行。
可能會留下一堆亂攤子 - 遺留的“爛”程式碼。
2.4、革新派
這一派主要是在“大泥球”單體開發上遇到了種種問題，想用新的技術架構-微服務架構來解決。
“大泥球”單體的問題：
- 程式碼腐化：業務程式碼經過長時間的迭代，有很多重複程式碼。比如一個功能可能有 3,4 種實現。
- 業務邏輯交織：業務應用經過長時間發展，功能變多，業務功能裡的邏輯程式碼可能相互引用，交織不清。
- 程式碼複雜：功能多，業務邏輯複雜，只有少數員工能理解。這也是程式碼腐化一種。
- 維護性變差：修改 bug 或增加新功能時，牽一髮而動全身。一個 bug 沒修好可能導致整個軟體不可用。
- 擴充套件性變差：增加新功能時，牽一髮而動全身。
- 編譯釋出變長：軟體程式碼量大，編譯時長變長，導致釋出時長也變長。
等等各種問題。
為了解決上面的問題，就想到微服務架構。微服務架構最基本的一個點：分而治之，由大化小。目的就是把一個大單體劃分為各種微服務，松耦合，獨立自治。
微服務的優點：
-
松耦合：劃分為一個一個小的微服務，程式碼之間邏輯交織降低。
-
獨立部署：每個劃分的微服務都是一個獨立的專案，可以獨立部署。
-
編譯釋出改善：劃分為獨立的小專案，編譯時長變短，釋出時長相應變短。
-
故障隔離：由於劃分為一個一個微服務，故障僅發生在獨立的微服內。
-
可擴充套件性：每個服務可以獨立橫向擴充套件，也可以從應用程式中提出獨立功能變成服務，擴充套件變強。
-
職責單一團隊：每個小的微服務都由一個小型的高度專注的團隊負責。
-
技術異構：每個團隊可以選擇適合該業務的技術。
看著微服務的這些優點，看著是解決了大單體的問題。
但是微服務自身就沒有缺點嗎？有的，整體架構複雜度變高。
微服務的各種缺點：
-
呼叫複雜性：單體應用是在本地呼叫，微服務是透過網路呼叫，有的還需要呼叫多個其它服務才能完成一個功能，其它服務不可用怎麼辦？
-
分散式複雜性：分散式資料一致性，分散式事務問題。
-
部署複雜性：服務變多，部署起來也變複雜。所示基礎設施CICD就變得重要。
-
服務治理：服務出現問題，找到問題的鏈路變長，所以就有鏈路監控。還有服務隔離和容錯。
-
測試複雜性：整合測試變得複雜，畢竟服務多。
-
運維複雜性：服務變多怎麼定位問題？怎麼保證服務穩定？
-
團隊協調複雜：微服務劃分後就涉及多個團隊溝通協作了。
等等，都是技術上遇到的問題。這些微服務的缺點也需要高度注意。
如果實施微服務，那麼技術基礎設施也需要及時跟進。
2.5 上面 4 派不妥之處是什麼？
對公司現階段業務實際情況進行調查，遇到了哪些問題？一一列出。
微服務架構能解決哪些問題？
兩者之間是匹配的嗎？如匹配，匹配多少呢？
大公司或者技術媒體關於微服務架構的文章，我們當然要學習消化，然後想在公司立馬應用起來。
這裡有一個根本問題就是：
發文章的人並不瞭解你公司的具體情況。公司現在有多少業務？每條業務線技術情況是什麼樣？有哪些問題？開發人員有多少？業務使用者每天訪問量有多少？等等，都不清楚。我們也不是淘寶、騰訊、京東這樣的大公司，他們這些技術方案都適合自己公司現狀嗎？
我們最後還是要關注自己公司情況，要具體問題具體分析。
按照公司現階段條件和問題做適當的選擇。
二、小公司需使用微服務架構嗎？
這裡所說的小公司，是指後端研發人員較少，30 人左右，專案數量 6 個左右。平均下來每個專案共有 5 名研發人員。
這樣的人員配置適合微服務架構開發嗎？適不適合要從各個方面來評估。
我前面也有寫微服務架構適用場景分析：
微服務架構學習與思考(05)：微服務架構適用場景分析
第一：業務發展階段
-
業務剛開始探索時期
這個時期最重要的目的是加快產品應用上市，驗證產品是否匹配市場。這時是一個 MVP 產品，功能少，適合用單體來快速開發。
-
高速發展時期
產品驗證取得了初步成功，進入業務快速迭代階段。這個階段一般也是用單體架構，快速開發功能。
-
產品穩定時期
業務功能迭代沒有那麼快，這時可以思考架構的問題，並尋找解決方法。微服務也只是一種比較好的選擇。
第二：業務複雜度
- 業務功能多，流程錯綜複雜，只有少數人能看懂，功能交付變長。這時可以利用改造微服務的機會，來梳理業務流程，理清彼此之間關係。
- 如果是相對簡單業務，那麼沒必要使用微服務。
第三：開發人員
-
技術熟練度
對微服務技術做了相應的預研，並且做了對應的練習實踐，對微服務涉及的技術有一定實踐經驗。
微服務技術體系本身就是由很多系統組成，技術體系本身就有一定的複雜性。
-
開發人員質和量
劃分微服務後，人員數量是否滿足劃分後的微服務？還是劃分後大家完成需求比較急？
微服務架構涉及到了很多技術系統，對人員技術要求也更高。
第四：業務形態
- 如果你是那種對效能要求很極致的業務，比如金融股票交易系統、遊戲裡的戰鬥系統燈光。這種就不適合，因為微服務網路呼叫相對於單體本地呼叫的開銷肯定更大。
更多需要考慮的點請檢視這篇文章：https://www.cnblogs.com/jiujuan/p/13762969.html
為什麼要考慮業務發展階段呢？
如果是專案剛啟動，第 1 點：要快速把專案開發出來，讓業務跑起來，給使用者使用，看能否對使用者產生價值。第 2 點：這時的產品功能不穩定，需求變化快，改動頻繁。第 3 點：這時產品功能少，不需要複雜的架構。要防止專案過度設計，影響開發進度。第 4 點：你無法預知未來，什麼未來？專案在未來是否會發展起來。
所以一般建議：一開始就用複雜微服務架構來做開始啟動的專案，不是一個良好的決策。
如果你能確定未來 1, 2 年內，專案會快速發展起來，那麼適當做超前架構設計，是可以的。避免 2 年後業務起來，架構重構的諸多麻煩。
遺憾的是，多數創業專案撐不過 2 年就以失敗告終。
剛開始的專案，單體架構是一個好的建議，需做好相應的模組劃分。然後隨著業務的發展，架構也隨之演進。
我前面的文章 “單體架構到微服務架構演進”：https://www.cnblogs.com/jiujuan/p/17066590.html
演進架構 是一種很好的架構方法，值得多思考。
說明：
這篇文章希望大家討論在中小公司中，哪些情況下使用微服務架構，更適合公司業務。並不是說一定不能使用微服務，選擇當下適合自己才是最好的。
如果大家意猶未盡，還可以到我的公眾號繼續- -!：九卷技術錄 - 小公司需要使用微服務架構嗎
以上就是九卷的一點看法，如有不對不妥的地方，歡迎大家批評指正。