序

網絡上介紹微服務的文章很多，但是針對小規模團隊如何實踐微服務架構的文章很少，而照搬大公司的做法并不完全適合，很容易失敗。
筆者在這個過程中也走過很多彎路，所以寫了這篇文章，一方面做一個整理總結，更多的是希望能拋磚引玉，幫助他人，也被他人幫助。
本文通過公司一個近期的實際產品，從0到1介紹設計和實現的過程。
限于個人的能力和經驗，難免有不足之處，所以誠惶誠恐，希望得到大家的指正。

個人對于微服務的理解

思想的高度決定行動的水平，我理解的微服務應該是這樣的。

1. 微服務是一種思想，然后才是技術。
2. 微服務的核心思想是化繁為簡。
3. 微服務是一個理想，對于微服務不能完美實現的系統，可以混合傳統方式實現。
4. 微服務是需要迭代的，很難一步到位。

微服務思維

整個團隊包括產品、設計、研發、測試、運維都應該具備微服務思維。
整個團隊包括產品、設計、研發、測試、運維都應該具備微服務思維。
整個團隊包括產品、設計、研發、測試、運維都應該具備微服務思維。
重要的事情說三遍。
既然是一種思想，首先的，整個團隊要統一認識。

認識誤區

對于微服務，經常有一個認識上的誤區，產品和設計只關注完整的業務流程和輸出高保真，微服務化的工作交給技術去做。這是很多團隊失敗的重要原因，我們也犯過同樣的錯誤。其導致的問題包括：

1. 產品和研發對于工作量的估計偏差很大。
   成功微服務架構的特點是，前期設計開發工作量大，后期維護和升級的工作量小，傳統單體應用剛好相反。
   在前期，微服務設計考慮的東西比傳統單體應用多很多，單體應用關注接口、流程、模塊化、數據結構，而微服務首先要考慮服務劃分，權衡劃分粒度，服務之間的層級、調用、解耦等關系及部署時的組合、調度等等問題，同時每個被劃分好的微服務也是一個單體應用，除了需要考慮單體應用關注的接口、流程、模塊化、數據結構，還要考慮微服務之間的數據同步問題等等。
   產品迭代的第一個版本，微服務可能已經有超過10個，例如：基礎服務統一配置 config, 路由Gateway，權限Acl，通用用戶User，單點登陸SSO, 通行證Passport, 以及微信相關服務 Wechat，Weapp，passport-weapp， passport-wechat，還有一些業務邏輯系統。
   這時候開發人員面臨的決定就非常艱難，如果先劃分，第一個版本開發周期估計至少要一個月以上，如果先做在一起，后期再劃分，勢必造成很多額外重構工作，費時費力。而產品給的時間只有一個周，要包含設計、開發、測試、上線，因為產品按照傳統單體應用估算工作量，而且還要求快速迭代，他們只關心結果。所以，常常項目一啟動，就已經失敗了。
2. 產品需求的修改對于技術的影響非常大。
   啟動時基礎不好，微服務設計的必然不會很好，大多做成四不像，把一個單體應用做成了幾個單體應用，增加了整體的復雜度，產品需求的修改，往往牽一發動全身，工程師需要花費更多的時間修改，效率低，質量也得不到保證。
   微服務化的優點體現不出來，反而放大了缺點。

缺乏微服務思維的團隊，千萬不要微服務，千萬不要微服務，千萬不要微服務。
不然技術團隊很難做，產品團隊也很難做。

產品的微服務思維

前面說了，微服務架構的核心思想是化繁為簡，需要考慮兩個步驟，先化整為零，把每個部分處理好后，再組合為一個整體。這兩個步驟需要反復執行，不斷優化。
產品的設計至少包含兩部分，看的見的和看不見的。產品經理需要把產品拆散和抽象為最小單位產品-微產品，逐個打磨好，再組合在一起。而后續的升級也更多的是針對微產品。每個微產品都解決自己范圍內的用戶需求，有自己的功能清單，生命周期，微產品之間有清晰的邊界和關系。
按這種思維設計的產品，技術實現就容易做的多了，因為大家站在一個維度上，討論的東西更加具體了。一個微產品，技術部門對應用一個或者以上的微服務實現。對于微產品的功能升級，也只會影響到范圍內的幾個微服務。這是非常棒的產品團隊。

下面開始介紹我們團隊的實踐過程。

產品目標

基于微信小程序實現一個互聯網醫療平臺，核心流程包含在線問診、處方、支付和藥品配送4個功能。

團隊

總結我們團隊的特點，也是很多小規模團隊的共同特點。

1. 團隊從零組建，成員流失率大，非常不穩定。
2. 預算有限，團隊規模小，成員間專業水平差異大。
3. 與大廠團隊比較，團隊整體專業能力和經驗都不足。
4. 工作壓力大，常態加班，團隊缺乏專門成長空間。

我們經過了大約2個月時間才形成了一個相對穩定的小團隊。

• 產品+設計
  產品負責人1人。
  產品經理1人。
  高級設計師1人。
• 研發
  技術負責人1人。
  高級后端工程師1人。
  高級前端工程師1人。
  高級測試工程師1人。
  高級運維工程師 1人。
  后端工程師1人。
  前端工程師1人。

技術選型

我們是小團隊，希望前后端統一開發語言，所以選擇了JavaScript。

• 前端
  Taro 用于開發小程序。
  jm-ant-design-pro 基于Ant Design Pro 實現模塊獨立化及自動化加載，用于開發管理后臺。
• 后端
  Node.js
  jm-ms 筆者自研的基于express，ws的微服務框架。
• 數據庫
  mongodb
  mysql
  redis
  kafka
• 運維部署
  rancher + docker
  阿里云
• 工具
  git
  webstorm

過程管理

Scrum敏捷開發，團隊協作工具：teambition。

總體設計

服務分層

產品的各個部分是有主次之分的，可以劃分為核心業務和前臺業務，通常20%的核心業務產生80%的價值。所以整個團隊80%的主要力量應該投入到核心業務。
對于技術團隊而言，除了關注業務分層，還要關心基礎服務。
服務分層適用于所有角色，是確認各種任務優先級的依據。
總體來講，共分為三層，如圖所示。

image.png

1. 基礎服務，按月更新
   關注安全性、可用性、可伸縮性、可擴展性、可管理性和經濟性。
   主要提供基礎能力，包括配置、權限、單點登陸、用戶、護照、短信服務、驗證碼、消息隊列、基礎支付、路由等。
   這部分需求需要技術部門自己規劃和升級，是技術負責人的重要責任。
2. 核心業務，按周更新
   這一層非常類似大廠的技術中臺。
   關注安全性、可用性、可伸縮性、可擴展性、可管理性和經濟性。
   對于業務進行高度抽象整理后，提煉出來的核心業務功能，包括業務用戶、IM、產品、訂單、供應商、支付等，沉淀了主要業務數據。
   這部分需求需要產品部門規劃和升級，對于產品經理的經驗和遠見有很高的要求，決定了產品的結果。
3. 前臺業務，按天更新
   關注可用性、可伸縮性。
   這部分業務非常靈活多變，需要快速實現，并且盡量保持接口不改或者少改。需求需要產品和運營部門規劃和升級，盡量避免浪費。包含兩種目的的工作
   • 組合基礎服務和核心服務，必要的時候需要做少量開發工作，從而支持到具體的業務場景。
   • 對于尚未清晰的業務，進行試錯性開發，快速驗證業務可行性，驗證成功后，重構為核心業務。

產品

限于篇幅，這里只討論產品的核心業務流程。

需求分析

產品的目的，一個是收入，一個是提高就醫效率。其中收入來源于問診費和處方費用，都是由患者支付的。
分析核心流程后，可以拆分為5個微產品，分別是問診、IM、處方、訂單及支付。產生的數據包括醫生、患者、問診單、處方、IM消息、藥品、訂單及付款單。
這里需要注意的是，醫生、患者和藥品又可以拆分為3個微產品，其中醫生、患者因為有共性，也可以作為一個微產品（用戶）考慮，我個人建議分開，比較清晰。
對于每個微產品，都應該分別獨立考慮，包括可見部分和不可見部分。同時考慮好與其他微產品的關系。
通常，良好的設計應該保證微產品之間的數據流是單向無循環的。

前端

包括小程序和管理后臺，都發布為SPA。

后端

分層邏輯視圖：

分層邏輯視圖

按請求流程觀察的邏輯視圖：

請求邏輯視圖

討論

微產品和微服務是什么關系？

個人理解他們本質是相同的，分別從產品和技術人員的角度抽象和拆散同一一個業務。我認為團隊協作的最好結果，就是產品和技術拆散的東西高度一致，只不過技術拆散的粒度可能更細。