微服務化架構演進與人員組織
阿新 • • 發佈：2019-01-25
微服務架構思路對組織影響的進一步思考。」
今年開始系統演化進入了第四個大版本，前兩個版本我們採用的單一應用模式，核心開發團隊也只有五、六人。
前年團隊擴張到了近 20 人左右，單一應用的維護協作成本已變得不可忽視，服務化拆分時進入第三版時我們做出
的一個選擇，但當時拆分粒度其實較粗，方便把團隊拆分為幾個小組來分別維護不同的服務和子系統。
兩年來隨著業務的發展，每個當初拆分的子系統或服務都膨脹到了一定的複雜度。單一程序應用實際承載了數十個
業務服務，單人維護單一服務程序應用開始變得有負擔，而類同業務大量需求導致的定製化開發嚴重拖累團隊的生產力，
進一步的微服務化與業務元件平臺化將是進入第四版的主題。
微服務的粒度
隨著公司運維基礎設施（編譯、部署、釋出、監控和預警）的逐步成熟為微服務化的生產應用鋪平了道路。微服務拆分遵循了兩個緯度，一個是業務服務分級化、目前定為三級（0、1、2），0 級服務為最核心，而越是核心
的業務拆分的職責越單一和正交化，實現功能的最小集，足夠的簡單單一對於確保穩定、效能和控制變更都有莫大益處，
邊際成本遞減效應明顯。
微服務規劃與設計
當我們開始考慮到底需要拆除哪些服務時，與城市規劃有些類似。首先一個城市會化成幾個大的片區，每個片區承擔著城市發展所需要不同功能職責（商業、居住、工業、科技等）。只有大的片區劃分是不夠的，
僅僅完成了頂層設計，微服務化的設計需進一步深入到這個片區到底是否需要安置一個 “購物中心”或“學校” 之類，
微服務化設計完成後，每個微服務的契約與主要職責就應該像 “購物中心”或“學校” 這樣的描述那麼明確了。
微服務功能職責僅僅是服務契約中的一部分，另一部分則是非功能規約。例如一個 “購物中心” 的確定則隱含對
周圍的交通流量提出了要求，否則過於擁堵的交通壓力會影響 “購物中心” 功能的可用性。
因此當設計一個微服務的契約時，我們需要描述清楚它提供的功能職責、承諾的響應時間分佈、承載的最大流量（TPS）等設計要素。
人員角色的變化
按微服務拆分系統後，按照 “服務即產品” 的思路，人員角色將發生變化。普通工程師從僅僅開發功能到開發、運營服務，工作性質的轉變將帶來思路和關注點的變化。
每個服務至少有一個工程師作為負責人，當然能力更強的人可能會負責更多的服務。
大量拆分的微服務帶來開發人員交集的減少，對於大規模的團隊並行開發好處明顯。
而服務負責制對個人能力要求更高，自驅動和自學習能力更強的人會得到更多的成長機會，個人成長路線的發展也打開了空間。
這時團隊的構成會變得類似 NBA 球隊的組成，工程師的角色類似球員，架構師或技術經理類似主教練，而部門經理則是球隊經理。
球員只管打好球，教練負責球員訓練、培養與戰術安排，經理則掌握著人事權，控制著球員的薪水升遷，招聘到優秀的球員。
一隻籃球隊場上實際只有五個位置，對應不同服務的負責人，如果人員少於服務分類，實際會有能力強的球員同時打多個位置。
而當人員多於服務分類時，必然有人是首發主力隊員，而有人則是後補隊員，甚至也有人是長期坐冷板凳的。
誰能成為首發主力，甚至成長為明星球員這多取決於個人努力、能力以及比賽的受歡迎程度。
球隊要打出好成績需要優秀的球員、教練相互默契的配合，這一點也是與按微服務化組織的開發團隊相一致的。
當然最好能在更受歡迎比賽上打球。