服务设计思考：平台化

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

总览

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

关系

实现：
 ● 如何实现需求的快速响应？明确的方向，清晰的边界。确认通用语言，核心领域。敏捷开发，快速迭代。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 版本管理，标准化，敏捷开发。

文章转载自公众号：码哥字节