服务设计思考：平台化

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

目标：

• 对需求方： 快速响应。能够敏捷地进行需求迭代。

• 对第三方业务方： 以产品的方式提供服务。所见即所得。全部功能对业务方透明。

• 对测试方： 简易明了的测试方式。利于自动化测试，灰度测试。

• 对运维方： 持续集成，自动化编排，自动化部署。

• 数据方： 提供多维度，详尽的服务数据。能够给数据方提供简便的数据分析。

• 内部开发： 敏捷开发。迅速集成。

实现：

• 如何实现需求的快速响应？
  明确的方向，清晰的边界。确认通用语言，核心领域。敏捷开发，快速迭代。AB 测试。

• 如何为第三方提供产品式的服务？

  所见即所得。详尽的文档。第三方调试平台，第三方管理平台。

• mock 服务，自动化测试，swagger 文档。

• Devops，CI，DI 等持续集成，服务监控。

• 业务数据与分析数据异构存储。提供易于分析的数据服务。

• 组内服务负责制度，人类最佳的合做人数是 2-3 人。因此两人维护一个项目，一人主导，一人辅助，两人交叉合做是一个很好的团队合做模式。如图造成一个网状模式(红色线表明主导，黑色线辅助)。这样每个项目都将有两个熟悉的人。

原则

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

实施

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

1. 抽离变化与不变。造成基础服务

   以下面一套用户体系，将服务抽离，将变与不变隔离。

   用户 api： 主要提供用户相关的接口，变化大，更偏向于业务；

   用户中心： 主要管理用户核心领域，变更不大，需稳定高可用的服务；

   鉴权受权中心： 变更不大，主要管理用户凭证核心领域；

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 版本管理，标准化，敏捷开发。

欢迎关注个人公众号。