服务设计思考：平台化
平台是一套完整的服务。也是一套内部自洽的系统。核心在于 分离 ，业务与通用服务隔离，业务与通用功能隔离。
目标：
-
对需求方：快速响应。可以敏捷地进行需求迭代。
-
对第三方业务方：以产品的方式提供服务。所见即所得。所有功能对业务方透明。
-
对测试方：简易明了的测试方式。利于自动化测试，灰度测试。
-
对运维方：持续集成，自动化编排，自动化部署。
-
数据方：提供多维度，详尽的服务数据。可以给数据方提供简便的数据分析。
-
内部开发：敏捷开发。迅速集成。
实现：
-
如何实现需求的快速响应？
明确的方向，清晰的边界。确认通用语言，核心领域。敏捷开发，快速迭代。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 版本管理，标准化，敏捷开发。
欢迎关注我的公众号。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
