技術大環境分析，到目前為止（2023.02）技術大環境：
這樣的氛圍下，微服務這 3 個字時不時的出現在眼前，加深你對它的印象。有時會給人帶來一種「幻覺」，如果自家公司技術不進行微服務的升級改造，技術就會落後於它們，對技術產生焦慮感。
這種屬於「跟風派」。完全沒有考慮自家業務發展情況，反正別家公司都是這麼做的，我也要這麼做。
有的技術人，在出現新的技術時，都想要在自家業務上對新技術實踐一番，以此體驗新的技術給他們帶來的一種「技術快感」。
「我使用了 NB 的技術」。為了技術而技術。
我意思不是說，對新技術不追求。
對於個人而言，這是一種「活到老，學到老」的積極學習態度，是值得大加提倡。
對於公司而言，需要考慮的情況比較複雜，至少有以下 3 點：
這種喜歡新技術的人，可以做公司技術預研，為將來遇到合適的業務應用這種技術打好基礎。
好多招聘 java 開發的，都寫著一個技能要求，熟悉 springcloud 並使用。
springcloud 是 java 語言的一個微服務開發技術棧大整合框架。
招聘，這也導致一些人嘗試使用微服務架構，為一下次跳槽做好準備。
這種情況於個人是一種驅動力，於公司則需要三思而行。
可能會留下一堆亂攤子 - 遺留的「爛」程式碼。
這一派主要是在「大泥球」單體開發上遇到了種種問題，想用新的技術架構-微服務架構來解決。
「大泥球」單體的問題：
等等各種問題。
為了解決上面的問題，就想到微服務架構。微服務架構最基本的一個點：分而治之，由大化小。目的就是把一個大單體劃分為各種微服務，鬆耦合，獨立自治。
微服務的優點：
鬆耦合：劃分為一個一個小的微服務，程式碼之間邏輯交織降低。
獨立部署：每個劃分的微服務都是一個獨立的專案，可以獨立部署。
編譯釋出改善：劃分為獨立的小專案，編譯時長變短，釋出時長相應變短。
故障隔離：由於劃分為一個一個微服務，故障僅發生在獨立的微服內。
可延伸性：每個服務可以獨立橫向擴充套件，也可以從應用程式中提出獨立功能變成服務，擴充套件變強。
職責單一團隊：每個小的微服務都由一個小型的高度專注的團隊負責。
技術異構：每個團隊可以選擇適合該業務的技術。
看著微服務的這些優點，看著是解決了大單體的問題。
但是微服務自身就沒有缺點嗎？有的，整體架構複雜度變高。
微服務的各種缺點：
呼叫複雜性：單體應用是在本地呼叫，微服務是通過網路呼叫，有的還需要呼叫多個其它服務才能完成一個功能，其它服務不可用怎麼辦？
分散式複雜性：分散式資料一致性，分散式事務問題。
部署複雜性：服務變多，部署起來也變複雜。所示基礎設施CICD就變得重要。
服務治理：服務出現問題，找到問題的鏈路變長，所以就有鏈路監控。還有服務隔離和容錯。
測試複雜性：整合測試變得複雜，畢竟服務多。
運維複雜性：服務變多怎麼定位問題？怎麼保證服務穩定？
團隊協調複雜：微服務劃分後就涉及多個團隊溝通共同作業了。
等等，都是技術上遇到的問題。這些微服務的缺點也需要高度注意。
如果實施微服務，那麼技術基礎設施也需要及時跟進。
對公司現階段業務實際情況進行調查，遇到了哪些問題？一一列出。
微服務架構能解決哪些問題？
兩者之間是匹配的嗎？如匹配，匹配多少呢？
大公司或者技術媒體關於微服務架構的文章，我們當然要學習消化，然後想在公司立馬應用起來。
這裡有一個根本問題就是：
發文章的人並不瞭解你公司的具體情況。公司現在有多少業務？每條業務線技術情況是什麼樣？有哪些問題？開發人員有多少？業務使用者每天存取量有多少？等等，都不清楚。我們也不是淘寶、騰訊、京東這樣的大公司，他們這些技術方案都適合自己公司現狀嗎？
我們最後還是要關注自己公司情況，要具體問題具體分析。
按照公司現階段條件和問題做適當的選擇。
這裡所說的小公司，是指後端研發人員較少，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
演進架構 是一種很好的架構方法，值得多思考。
以上就是九卷的一點看法，如有不對不妥的地方，歡迎大家批評指正。