服務設計思考:平臺化
阿新 • • 發佈:2020-06-19
平臺是一套完整的服務。也是一套內部自洽的系統。核心在於**分離**,業務與通用服務隔離,業務與通用功能隔離。
![總覽](https://magebyte.oss-cn-shenzhen.aliyuncs.com/other/overview.jpg)
## 目標:
- **對需求方:** 快速響應。可以敏捷地進行需求迭代。
- **對第三方業務方:** 以產品的方式提供服務。所見即所得。所有功能對業務方透明。
- **對測試方:** 簡易明瞭的測試方式。利於自動化測試,灰度測試。
- **對運維方:** 持續整合,自動化編排,自動化部署。
- **資料方:** 提供多維度,詳盡的服務資料。可以給資料方提供簡便的資料分析。
- **內部開發:** 敏捷開發。迅速整合。
![關係](https://magebyte.oss-cn-shenzhen.aliyuncs.com/other/relation.jpg)
## 實現:
- 如何實現需求的快速響應?
明確的方向,清晰的邊界。確認通用語言,核心領域。敏捷開發,快速迭代。AB 測試。
- 如何為第三方提供產品式的服務?
所見即所得。詳盡的文件。第三方除錯平臺,第三方管理平臺。
- mock 服務,自動化測試,swagger 文件。
- Devops,CI,DI 等持續整合,服務監控。
- 業務資料與分析資料異構儲存。提供易於分析的資料服務。
- 組內服務負責制度,人類最佳的合作人數是 2-3 人。所以兩人維護一個專案,一人主導,一人輔助,兩人交叉合作是一個很好的團隊合作模式。如圖形成一個網狀模式(紅色線代表主導,黑色線輔助)。這樣每一個專案都將有兩個熟悉的人。
![團隊合作](https://magebyte.oss-cn-shenzhen.aliyuncs.com/other/team.jpg)
## 原則
1. 單一職責。
2. 業務關注業務,功能關注功能。
3. 確認邊界,確認核心領域。
4. 所見即所得。
## 實施
#### 如何推進業務開發快速響應?
1. 抽離變化與不變。形成基礎服務
如下面一套使用者體系,將服務抽離,將變與不變隔離。
**使用者 api:** 主要提供使用者相關的介面,變化大,更偏向於業務;
**使用者中心:** 主要管理使用者核心領域,變動不大,需穩定高可用的服務;
**鑑權授權中心:** 變動不大,主要管理使用者憑證核心領域;
![](https://magebyte.oss-cn-shenzhen.aliyuncs.com/other/server.jpg)
2. 抽離通用功能。
那些非業務的通用功能應隔離於業務之外:**元件化**,**工具化**,**服務化**。
如`來源監控`,`介面限流`,`日誌分析`,`應用監控`,`服務依賴`,`配置管理`,`系統部署`等(業務人員不必關心這些功能相關的事情,只需要關注於具體的業務領域)。關注點分離。
如上面所涉及的,從`Spring Cloud`的各大元件可以看出,最終的方案都將走上相近的道路。
3) 領域上下文劃分。劃分微服務專案。業務隔離,資料去中心化。服務元件化。
Spring cloud 技術棧:
- **服務治理:** 註冊中心,服務呼叫,衍生的容錯(熔斷器)
- **api 閘道器:** 來源監控,介面限流(Spring Cloud gateway、zuul)
- **配置中心: ** 配置管理(Apollo)
- **自動化部署:** Jenkins、docker、k8s
- **日誌與監控:** prometheus、influxdb、skywalking、elk
- **資料視覺化:** druid、kylin、superset
4. 細節管控
介面版本管理, gitflow 管理,專案迭代 release 版本管理,標準化,敏捷開發。
> 歡迎關注我的公眾號。
![碼哥位元組](https://magebyte.oss-cn-shenzhen.aliyuncs.com/wechat/%E7%A0%81%E5%93%A5%E5%AD%97%E8%8A%82%E4%BA%8C%E7%BB%B4%E7%A0%