服务设计思考：平台化

平台是一套完整的服务。也是一套内部自洽的系统。核心在于分离，业务与通用服务隔离，业务与通用功能隔离。

总览

目标：

• 对需求方： 快速响应。可以敏捷地进行需求迭代。
• 对第三方业务方： 以产品的方式提供服务。所见即所得。所有功能对业务方透明。
• 对测试方： 简易明了的测试方式。利于自动化测试，灰度测试。
• 对运维方： 持续集成，自动化编排，自动化部署。
• 数据方： 提供多维度，详尽的服务数据。可以给数据方提供简便的数据分析。
• 内部开发： 敏捷开发。迅速集成。

关系

实现：

• 如何实现需求的快速响应？明确的方向，清晰的边界。确认通用语言，核心领域。敏捷开发，快速迭代。AB 测试。
• 如何为第三方提供产品式的服务？ 所见即所得。详尽的文档。第三方调试平台，第三方管理平台。
• mock 服务，自动化测试，swagger 文档。
• Devops，CI，DI 等持续集成，服务监控。
• 业务数据与分析数据异构存储。提供易于分析的数据服务。
• 组内服务负责制度，人类最佳的合作人数是 2-3 人。所以两人维护一个项目，一人主导，一人辅助，两人交叉合作是一个很好的团队合作模式。如图形成一个网状模式(红色线代表主导，黑色线辅助)。这样每一个项目都将有两个熟悉的人。

团队合作

原则

1. 单一职责。
2. 业务关注业务，功能关注功能。
3. 确认边界，确认核心领域。
4. 所见即所得。

实施

如何推进业务开发快速响应？

1. 抽离变化与不变。形成基础服务 如下面一套用户体系，将服务抽离，将变与不变隔离。 **用户 api：**主要提供用户相关的接口，变化大，更偏向于业务； **用户中心：**主要管理用户核心领域，变动不大，需稳定高可用的服务； 鉴权授权中心： 变动不大，主要管理用户凭证核心领域；

1. 抽离通用功能。 那些非业务的通用功能应隔离于业务之外：组件化，工具化，服务化。 如来源监控，接口限流，日志分析，应用监控，服务依赖，配置管理，系统部署等（业务人员不必关心这些功能相关的事情，只需要关注于具体的业务领域）。关注点分离。 如上面所涉及的，从Spring Cloud的各大组件可以看出，最终的方案都将走上相近的道路。
2. 领域上下文划分。划分微服务项目。业务隔离，数据去中心化。服务组件化。 Spring cloud 技术栈：
   • 服务治理： 注册中心，服务调用，衍生的容错（熔断器）
   • api 网关： 来源监控，接口限流(Spring Cloud gateway、zuul)
   • **配置中心：** 配置管理(Apollo)
   • 自动化部署： Jenkins、docker、k8s
   • 日志与监控： prometheus、influxdb、skywalking、elk
   • 数据可视化： druid、kylin、superset
3. 细节管控 接口版本管理， gitflow 管理，项目迭代 release 版本管理，标准化，敏捷开发。