序

網(wǎng)絡(luò)上介紹微服務(wù)的文章很多，但是針對小規(guī)模團(tuán)隊(duì)如何實(shí)踐微服務(wù)架構(gòu)的文章很少蠢挡，而照搬大公司的做法并不完全適合弧岳，很容易失敗。
筆者在這個(gè)過程中也走過很多彎路业踏，所以寫了這篇文章缩筛，一方面做一個(gè)整理總結(jié)，更多的是希望能拋磚引玉堡称，幫助他人瞎抛，也被他人幫助。
本文通過公司一個(gè)近期的實(shí)際產(chǎn)品却紧，從0到1介紹設(shè)計(jì)和實(shí)現(xiàn)的過程桐臊。
限于個(gè)人的能力和經(jīng)驗(yàn)，難免有不足之處晓殊，所以誠惶誠恐断凶，希望得到大家的指正。

個(gè)人對于微服務(wù)的理解

思想的高度決定行動(dòng)的水平巫俺，我理解的微服務(wù)應(yīng)該是這樣的认烁。

1. 微服務(wù)是一種思想，然后才是技術(shù)介汹。
2. 微服務(wù)的核心思想是化繁為簡却嗡。
3. 微服務(wù)是一個(gè)理想，對于微服務(wù)不能完美實(shí)現(xiàn)的系統(tǒng)嘹承，可以混合傳統(tǒng)方式實(shí)現(xiàn)窗价。
4. 微服務(wù)是需要迭代的，很難一步到位叹卷。

微服務(wù)思維

整個(gè)團(tuán)隊(duì)包括產(chǎn)品撼港、設(shè)計(jì)、研發(fā)骤竹、測試帝牡、運(yùn)維都應(yīng)該具備微服務(wù)思維。
整個(gè)團(tuán)隊(duì)包括產(chǎn)品蒙揣、設(shè)計(jì)靶溜、研發(fā)、測試鸣奔、運(yùn)維都應(yīng)該具備微服務(wù)思維墨技。
整個(gè)團(tuán)隊(duì)包括產(chǎn)品惩阶、設(shè)計(jì)、研發(fā)扣汪、測試断楷、運(yùn)維都應(yīng)該具備微服務(wù)思維。
重要的事情說三遍崭别。
既然是一種思想冬筒，首先的，整個(gè)團(tuán)隊(duì)要統(tǒng)一認(rèn)識茅主。

認(rèn)識誤區(qū)

對于微服務(wù)舞痰，經(jīng)常有一個(gè)認(rèn)識上的誤區(qū)，產(chǎn)品和設(shè)計(jì)只關(guān)注完整的業(yè)務(wù)流程和輸出高保真诀姚，微服務(wù)化的工作交給技術(shù)去做响牛。這是很多團(tuán)隊(duì)失敗的重要原因，我們也犯過同樣的錯(cuò)誤赫段。其導(dǎo)致的問題包括：

1. 產(chǎn)品和研發(fā)對于工作量的估計(jì)偏差很大呀打。
   成功微服務(wù)架構(gòu)的特點(diǎn)是，前期設(shè)計(jì)開發(fā)工作量大糯笙，后期維護(hù)和升級的工作量小贬丛，傳統(tǒng)單體應(yīng)用剛好相反。
   在前期给涕，微服務(wù)設(shè)計(jì)考慮的東西比傳統(tǒng)單體應(yīng)用多很多豺憔，單體應(yīng)用關(guān)注接口、流程够庙、模塊化恭应、數(shù)據(jù)結(jié)構(gòu)，而微服務(wù)首先要考慮服務(wù)劃分首启，權(quán)衡劃分粒度暮屡，服務(wù)之間的層級、調(diào)用毅桃、解耦等關(guān)系及部署時(shí)的組合、調(diào)度等等問題准夷，同時(shí)每個(gè)被劃分好的微服務(wù)也是一個(gè)單體應(yīng)用钥飞，除了需要考慮單體應(yīng)用關(guān)注的接口、流程衫嵌、模塊化读宙、數(shù)據(jù)結(jié)構(gòu)，還要考慮微服務(wù)之間的數(shù)據(jù)同步問題等等楔绞。
   產(chǎn)品迭代的第一個(gè)版本结闸，微服務(wù)可能已經(jīng)有超過10個(gè)唇兑，例如：基礎(chǔ)服務(wù)統(tǒng)一配置 config, 路由Gateway，權(quán)限Acl桦锄，通用用戶User扎附，單點(diǎn)登陸SSO, 通行證Passport, 以及微信相關(guān)服務(wù) Wechat，Weapp结耀，passport-weapp留夜， passport-wechat，還有一些業(yè)務(wù)邏輯系統(tǒng)图甜。
   這時(shí)候開發(fā)人員面臨的決定就非常艱難碍粥，如果先劃分，第一個(gè)版本開發(fā)周期估計(jì)至少要一個(gè)月以上黑毅，如果先做在一起嚼摩，后期再劃分，勢必造成很多額外重構(gòu)工作矿瘦，費(fèi)時(shí)費(fèi)力低斋。而產(chǎn)品給的時(shí)間只有一個(gè)周，要包含設(shè)計(jì)匪凡、開發(fā)膊畴、測試、上線病游，因?yàn)楫a(chǎn)品按照傳統(tǒng)單體應(yīng)用估算工作量唇跨，而且還要求快速迭代，他們只關(guān)心結(jié)果衬衬。所以买猖，常常項(xiàng)目一啟動(dòng)，就已經(jīng)失敗了滋尉。
2. 產(chǎn)品需求的修改對于技術(shù)的影響非常大玉控。
   啟動(dòng)時(shí)基礎(chǔ)不好，微服務(wù)設(shè)計(jì)的必然不會很好狮惜，大多做成四不像高诺，把一個(gè)單體應(yīng)用做成了幾個(gè)單體應(yīng)用，增加了整體的復(fù)雜度碾篡，產(chǎn)品需求的修改虱而，往往牽一發(fā)動(dòng)全身，工程師需要花費(fèi)更多的時(shí)間修改开泽，效率低牡拇，質(zhì)量也得不到保證。
   微服務(wù)化的優(yōu)點(diǎn)體現(xiàn)不出來，反而放大了缺點(diǎn)惠呼。

缺乏微服務(wù)思維的團(tuán)隊(duì)导俘，千萬不要微服務(wù)，千萬不要微服務(wù)剔蹋，千萬不要微服務(wù)旅薄。
不然技術(shù)團(tuán)隊(duì)很難做，產(chǎn)品團(tuán)隊(duì)也很難做滩租。

產(chǎn)品的微服務(wù)思維

前面說了赋秀，微服務(wù)架構(gòu)的核心思想是化繁為簡，需要考慮兩個(gè)步驟律想，先化整為零猎莲，把每個(gè)部分處理好后，再組合為一個(gè)整體技即。這兩個(gè)步驟需要反復(fù)執(zhí)行著洼，不斷優(yōu)化。
產(chǎn)品的設(shè)計(jì)至少包含兩部分而叼，看的見的和看不見的身笤。產(chǎn)品經(jīng)理需要把產(chǎn)品拆散和抽象為最小單位產(chǎn)品-微產(chǎn)品，逐個(gè)打磨好葵陵，再組合在一起液荸。而后續(xù)的升級也更多的是針對微產(chǎn)品仇冯。每個(gè)微產(chǎn)品都解決自己范圍內(nèi)的用戶需求传黄，有自己的功能清單癞埠，生命周期额湘，微產(chǎn)品之間有清晰的邊界和關(guān)系。
按這種思維設(shè)計(jì)的產(chǎn)品船殉，技術(shù)實(shí)現(xiàn)就容易做的多了瑰枫，因?yàn)榇蠹艺驹谝粋€(gè)維度上穷蛹，討論的東西更加具體了秤朗。一個(gè)微產(chǎn)品煤蹭，技術(shù)部門對應(yīng)用一個(gè)或者以上的微服務(wù)實(shí)現(xiàn)。對于微產(chǎn)品的功能升級取视，也只會影響到范圍內(nèi)的幾個(gè)微服務(wù)硝皂。這是非常棒的產(chǎn)品團(tuán)隊(duì)。

下面開始介紹我們團(tuán)隊(duì)的實(shí)踐過程贫途。

產(chǎn)品目標(biāo)

基于微信小程序?qū)崿F(xiàn)一個(gè)互聯(lián)網(wǎng)醫(yī)療平臺吧彪，核心流程包含在線問診、處方丢早、支付和藥品配送4個(gè)功能。

團(tuán)隊(duì)

總結(jié)我們團(tuán)隊(duì)的特點(diǎn)，也是很多小規(guī)模團(tuán)隊(duì)的共同特點(diǎn)怨酝。

1. 團(tuán)隊(duì)從零組建傀缩，成員流失率大，非常不穩(wěn)定农猬。
2. 預(yù)算有限赡艰，團(tuán)隊(duì)規(guī)模小，成員間專業(yè)水平差異大斤葱。
3. 與大廠團(tuán)隊(duì)比較慷垮，團(tuán)隊(duì)整體專業(yè)能力和經(jīng)驗(yàn)都不足。
4. 工作壓力大揍堕，常態(tài)加班料身，團(tuán)隊(duì)缺乏專門成長空間。

我們經(jīng)過了大約2個(gè)月時(shí)間才形成了一個(gè)相對穩(wěn)定的小團(tuán)隊(duì)衩茸。

• 產(chǎn)品+設(shè)計(jì)
  產(chǎn)品負(fù)責(zé)人1人芹血。
  產(chǎn)品經(jīng)理1人。
  高級設(shè)計(jì)師1人楞慈。
• 研發(fā)
  技術(shù)負(fù)責(zé)人1人幔烛。
  高級后端工程師1人。
  高級前端工程師1人囊蓝。
  高級測試工程師1人饿悬。
  高級運(yùn)維工程師 1人。
  后端工程師1人聚霜。
  前端工程師1人狡恬。

技術(shù)選型

我們是小團(tuán)隊(duì)，希望前后端統(tǒng)一開發(fā)語言俯萎，所以選擇了JavaScript傲宜。

• 前端
  Taro 用于開發(fā)小程序。
  jm-ant-design-pro 基于Ant Design Pro 實(shí)現(xiàn)模塊獨(dú)立化及自動(dòng)化加載夫啊，用于開發(fā)管理后臺函卒。
• 后端
  Node.js
  jm-ms 筆者自研的基于express，ws的微服務(wù)框架撇眯。
• 數(shù)據(jù)庫
  mongodb
  mysql
  redis
  kafka
• 運(yùn)維部署
  rancher + docker
  阿里云
• 工具
  git
  webstorm

過程管理

Scrum敏捷開發(fā)报嵌，團(tuán)隊(duì)協(xié)作工具：teambition。

總體設(shè)計(jì)

服務(wù)分層

產(chǎn)品的各個(gè)部分是有主次之分的熊榛，可以劃分為核心業(yè)務(wù)和前臺業(yè)務(wù)锚国，通常20%的核心業(yè)務(wù)產(chǎn)生80%的價(jià)值。所以整個(gè)團(tuán)隊(duì)80%的主要力量應(yīng)該投入到核心業(yè)務(wù)玄坦。
對于技術(shù)團(tuán)隊(duì)而言血筑，除了關(guān)注業(yè)務(wù)分層绘沉，還要關(guān)心基礎(chǔ)服務(wù)。
服務(wù)分層適用于所有角色豺总，是確認(rèn)各種任務(wù)優(yōu)先級的依據(jù)车伞。
總體來講，共分為三層喻喳，如圖所示另玖。

image.png

1. 基礎(chǔ)服務(wù)，按月更新
   關(guān)注安全性表伦、可用性谦去、可伸縮性、可擴(kuò)展性蹦哼、可管理性和經(jīng)濟(jì)性鳄哭。
   主要提供基礎(chǔ)能力，包括配置翔怎、權(quán)限窃诉、單點(diǎn)登陸、用戶赤套、護(hù)照飘痛、短信服務(wù)、驗(yàn)證碼容握、消息隊(duì)列宣脉、基礎(chǔ)支付、路由等剔氏。
   這部分需求需要技術(shù)部門自己規(guī)劃和升級塑猖，是技術(shù)負(fù)責(zé)人的重要責(zé)任。
2. 核心業(yè)務(wù)谈跛，按周更新
   這一層非常類似大廠的技術(shù)中臺羊苟。
   關(guān)注安全性、可用性感憾、可伸縮性蜡励、可擴(kuò)展性、可管理性和經(jīng)濟(jì)性阻桅。
   對于業(yè)務(wù)進(jìn)行高度抽象整理后凉倚，提煉出來的核心業(yè)務(wù)功能，包括業(yè)務(wù)用戶嫂沉、IM稽寒、產(chǎn)品、訂單趟章、供應(yīng)商杏糙、支付等慎王，沉淀了主要業(yè)務(wù)數(shù)據(jù)。
   這部分需求需要產(chǎn)品部門規(guī)劃和升級搔啊，對于產(chǎn)品經(jīng)理的經(jīng)驗(yàn)和遠(yuǎn)見有很高的要求柬祠，決定了產(chǎn)品的結(jié)果北戏。
3. 前臺業(yè)務(wù)负芋，按天更新
   關(guān)注可用性、可伸縮性嗜愈。
   這部分業(yè)務(wù)非常靈活多變旧蛾，需要快速實(shí)現(xiàn)，并且盡量保持接口不改或者少改蠕嫁。需求需要產(chǎn)品和運(yùn)營部門規(guī)劃和升級锨天，盡量避免浪費(fèi)。包含兩種目的的工作
   • 組合基礎(chǔ)服務(wù)和核心服務(wù)剃毒，必要的時(shí)候需要做少量開發(fā)工作病袄，從而支持到具體的業(yè)務(wù)場景。
   • 對于尚未清晰的業(yè)務(wù)赘阀，進(jìn)行試錯(cuò)性開發(fā)益缠，快速驗(yàn)證業(yè)務(wù)可行性，驗(yàn)證成功后基公，重構(gòu)為核心業(yè)務(wù)幅慌。

產(chǎn)品

限于篇幅，這里只討論產(chǎn)品的核心業(yè)務(wù)流程轰豆。

需求分析

產(chǎn)品的目的胰伍，一個(gè)是收入，一個(gè)是提高就醫(yī)效率酸休。其中收入來源于問診費(fèi)和處方費(fèi)用骂租，都是由患者支付的。
分析核心流程后斑司，可以拆分為5個(gè)微產(chǎn)品渗饮，分別是問診、IM陡厘、處方抽米、訂單及支付。產(chǎn)生的數(shù)據(jù)包括醫(yī)生糙置、患者云茸、問診單、處方谤饭、IM消息标捺、藥品懊纳、訂單及付款單。
這里需要注意的是亡容，醫(yī)生嗤疯、患者和藥品又可以拆分為3個(gè)微產(chǎn)品，其中醫(yī)生闺兢、患者因?yàn)橛泄残悦浚部梢宰鳛橐粋€(gè)微產(chǎn)品（用戶）考慮，我個(gè)人建議分開屋谭，比較清晰脚囊。
對于每個(gè)微產(chǎn)品，都應(yīng)該分別獨(dú)立考慮桐磁，包括可見部分和不可見部分悔耘。同時(shí)考慮好與其他微產(chǎn)品的關(guān)系。
通常我擂，良好的設(shè)計(jì)應(yīng)該保證微產(chǎn)品之間的數(shù)據(jù)流是單向無循環(huán)的衬以。

前端

包括小程序和管理后臺，都發(fā)布為SPA校摩。

后端

分層邏輯視圖：

分層邏輯視圖

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

請求邏輯視圖

討論

微產(chǎn)品和微服務(wù)是什么關(guān)系看峻？

個(gè)人理解他們本質(zhì)是相同的，分別從產(chǎn)品和技術(shù)人員的角度抽象和拆散同一一個(gè)業(yè)務(wù)秧耗。我認(rèn)為團(tuán)隊(duì)協(xié)作的最好結(jié)果备籽，就是產(chǎn)品和技術(shù)拆散的東西高度一致，只不過技術(shù)拆散的粒度可能更細(xì)分井。