微服務化架構演進與人員組織

本文來自本人獨立博客，更好的瀏覽體驗點擊這里

「微服務架構思路對組織影響的進1步思考。」


今年開始系統演變進入了第4個大版本，前兩個版本我們采取的單1利用模式，核心開發團隊也只有5、6人。
前年團隊擴大到了近 20 人左右，單1利用的保護協作本錢已變得不可忽視，服務化拆分時進入第3版時我們做出
的1個選擇，但當時拆分粒度其實較粗，方便把團隊拆分為幾個小組來分別保護不同的服務和子系統。

兩年來隨著業務的發展，每一個當初拆分的子系統或服務都膨脹到了1定的復雜度。單1進程利用實際承載了數10個
業務服務，單人保護單1服務進程利用開始變得有負擔，而類同業務大量需求致使的定制化開發嚴重拖累團隊的生產力，
進1步的微服務化與業務組件平臺化將是進入第4版的主題。

微服務的粒度

隨著公司運維基礎設施（編譯、部署、發布、監控和預警）的逐漸成熟為微服務化的生產利用鋪平了道路。
微服務拆分遵守了兩個緯度，1個是業務服務分級化、目前定為3級（0、1、2），0 級服務為最核心，而越是核心
的業務拆分的職責越單1和正交化，實現功能的最小集，足夠的簡單單1對確保穩定、性能和控制變更都有莫大好處，
邊際本錢遞減效應明顯。

微服務計劃與設計

當我們開始斟酌到底需要撤除哪些服務時，與城市計劃有些類似。首先1個城市會化成幾個大的片區，
每一個片區承當著城市發展所需要不同功能職責（商業、居住、工業、科技等）。只有大的片區劃分是不夠的，
僅僅完成了頂層設計，微服務化的設計需進1步深入到這個片區究竟是否需要安置1個 “購物中心”或“學校” 之類，
微服務化設計完成后，每一個微服務的契約與主要職責就應當像 “購物中心”或“學校” 這樣的描寫那末明確了。


微服務功能職責僅僅是服務契約中的1部份，另外一部份則是非功能規約。例如1個 “購物中心” 的肯定則隱含對
周圍的交通流量提出了要求，否則過于擁堵的交通壓力會影響 “購物中心” 功能的可用性。
因此當設計1個微服務的契約時，我們需要描寫清楚它提供的功能職責、許諾的響應時間散布、承載的最大流量（TPS）等設計要素。

人員角色的變化

按微服務拆分系統后，依照 “服務即產品” 的思路，人員角色將產生變化。
普通工程師從僅僅開發功能到開發、運營服務，工作性質的轉變將帶來思路和關注點的變化。
每一個服務最少有1個工程師作為負責人，固然能力更強的人可能會負責更多的服務。
大量拆分的微服務帶來開發人員交集的減少，對大范圍的團隊并行開發好處明顯。
而服務負責制對個人能力要求更高，自驅動和自學習能力更強的人會得到更多的成長機會，個人成長線路的發展也打開了空間。


這時候團隊的構成會變得類似 NBA 球隊的組成，工程師的角色類似球員，架構師或技術經理類似主教練，而部門經理則是球隊經理。
球員只管打好球，教練負責球員訓練、培養與戰術安排，經理則掌握著人事權，控制著球員的薪水升遷，招聘到優秀的球員。


1只籃球隊場上實際只有5個位置，對應不同服務的負責人，如果人員少于服務分類，實際會有能力強的球員同時打多個位置。
而當人員多于服務分類時，必定有人是首發主力隊員，而有人則是后補隊員，乃至也有人是長時間坐冷板凳的。
誰能成為首發主力，乃至成長為明星球員這多取決于個人努力、能力和比賽的受歡迎程度。


球隊要打出好成績需要優秀的球員、教練相互默契的配合，這1點也是與按微服務化組織的開發團隊相1致的。
固然最好能在更受歡迎比賽上打球。