服务设计思考：平台化
平台是一套完整的服务。也是一套内部自洽的系统。核心在于分离，业务与通用服务隔离，业务与通用功能隔离。
目标：
对需求方： 快速响应。可以敏捷地进行需求迭代。
对第三方业务方： 以产品的方式提供服务。所见即所得。所有功能对业务方透明。
对测试方： 简易明了的测试方式。利于自动化测试，灰度测试。
对运维方： 持续集成，自动化编排，自动化部署。
数据方： 提供多维度，详尽的服务数据。可以给数据方提供简便的数据分析。
内部开发： 敏捷开发。迅速集成。
实现：
如何实现需求的快速响应？明确的方向，清晰的边界。确认通用语言，核心领域。敏捷开发，快速迭代。AB 测试。
如何为第三方提供产品式的服务？
所见即所得。详尽的文档。第三方调试平台，第三方管理平台。
mock 服务，自动化测试，swagger 文档。
Devops，CI，DI 等持续集成，服务监控。
业务数据与分析数据异构存储。提供易于分析的数据服务。
组内服务负责制度，人类最佳的合作人数是 2-3 人。所以两人维护一个项目，一人主导，一人辅助，两人交叉合作是一个很好的团队合作模式。如图形成一个网状模式(红色线代表主导，黑色线辅助)。这样每一个项目都将有两个熟悉的人。
原则
单一职责。 业务关注业务，功能关注功能。 确认边界，确认核心领域。 所见即所得。
实施
如何推进业务开发快速响应？
抽离变化与不变。形成基础服务
如下面一套用户体系，将服务抽离，将变与不变隔离。
**用户 api：**主要提供用户相关的接口，变化大，更偏向于业务；
**用户中心：**主要管理用户核心领域，变动不大，需稳定高可用的服务；
鉴权授权中心： 变动不大，主要管理用户凭证核心领域；
抽离通用功能。
那些非业务的通用功能应隔离于业务之外：组件化，工具化，服务化。
如
来源监控，接口限流，日志分析，应用监控，服务依赖，配置管理，系统部署等（业务人员不必关心这些功能相关的事情，只需要关注于具体的业务领域）。关注点分离。如上面所涉及的，从
Spring Cloud的各大组件可以看出，最终的方案都将走上相近的道路。
领域上下文划分。划分微服务项目。业务隔离，数据去中心化。服务组件化。
Spring cloud 技术栈：
服务治理： 注册中心，服务调用，衍生的容错（熔断器） api 网关： 来源监控，接口限流(Spring Cloud gateway、zuul) **配置中心：** 配置管理(Apollo) 自动化部署： Jenkins、docker、k8s 日志与监控： prometheus、influxdb、skywalking、elk 数据可视化： druid、kylin、superset
细节管控
接口版本管理， gitflow 管理，项目迭代 release 版本管理，标准化，敏捷开发。
欢迎关注我的公众号。