為什麼大部分碼農做不了架構師？

為什麼大部分碼農做不了架構師？成為架構師，不僅僅是工作上的簡單積累，更需要主動接納工作外的大量知識。

本文是服務治理領域的一篇文章，著重從一些更貼近我們實際工作的角度來進行更抽象層次的剖析，分享一些我認為重要或者有意思的方法論和邏輯推演過程。希望能給想成為架構師的碼農們，在無論是業務應用還是基礎技術領域的服務治理提供一些參考。

01

我們到底需要什麼樣的微服務？

開篇之前，想問大家一個問題，我們需要什麼樣的服務治理？

這個問題很好回答，同時也很難回答。簡單來說，這取決於三要素的發展現狀。取決於你的組織、業務和系統的健康度、匹配度和成熟度。但這個形而上的“道”，如何轉換成形而下的“器”，確是需要結合實際場景 case by case 去思考的，沒有標準答案。

02

面向應用領域的指導原則

四個問題

網上有很多關於應該怎麼拆分服務的文章，更多偏向技術層面。此處不加以贅述，我們討論四個問題，也是經常困擾我們的四個重要問題：

1. 應該在什麼階段進行拆分？永遠不要過早地進行拆分。考慮下你的業務迭代速度是否會引起系統所有權和使用權的競爭，進一步反向制約迭代的效率；考慮下是不是大應用導致你技術升級優化和資源的使用上困難重重；考慮下公司的運維水平和團隊成員的素質是不是能夠支撐起更細粒度的微服務體系結構。你考慮清楚了這三點，你就知道你是否應該進行拆分了。

2. 應該按照什麼維度來拆？大原則上來說，按照業務領域進行拆分即可。在領域之內，進行分層拆解，將接入層、邏輯層和資料層複雜到一定程度的時候進行橫向拆解。

3. 服務拆分到多小算小？有一個說法是“確保兩個星期之內能夠重構”。我比較認同的一個說法—“足夠小就行”。沒有唯一的衡量標準，這個取決於你的業務發展速度，業務複雜度，技術棧異構程度。很多人的傾向是，更願意對一些功能在不明確後續發展的時候，儘量能不拆就不拆。這同樣也是我的建議。另外建議，確保一個服務只有一個團隊在維護，這能避免大量的問題。當你發現有多個團隊在維護的時候，說明你可能需要拆分了。

4. 微服務團隊需要多大？小團隊更容易具備戰鬥力和凝聚力，也能擁有更好的效率和對未來的應變能力。

03

面向技術領域的指導原則

面向技術領域，這個問題比處理上面的問題要更直接而明確，重要的是其中四個方向：

1. 可運營

2. 高可用

3. 高效能

4. 自動化與標準化

通過本場 Chat，我想分享給大家的一個觀點是，不僅要結合實際生產實踐來分析具體的系統架構，也可以通過對架構的剖析能進一步地去洞察設計者的意圖和思考邏輯，知其然而知其所以然，這是我認為架構師領域非常重要的一個技能！

感興趣的朋友可以掃碼閱讀完整原文

也可以來讀者圈裡給我提問~

▼

點選閱讀原文，掌握架構師的必備技能！！