服务设计思考:平台化

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

服务设计思考:平台化

目标:

  • 需求方:快速响应。可以敏捷地进行需求迭代。

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

  • 测试方:简易明了的测试方式。利于自动化测试,灰度测试。

  • 对运维方:持续集成,自动化编排,自动化部署

  • 数据方:提供多维度,详尽的服务数据。可以给数据方提供简便的数据分析。

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

服务设计思考:平台化

实现:

  • 如何实现需求的快速响应?

    明确的方向,清晰的边界。确认通用语言,核心领域。敏捷开发,快速迭代。AB 测试。

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

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

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

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

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

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

服务设计思考:平台化

原则

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

实施

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

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

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

    用户 api:主要提供用户相关的接口,变化大,更偏向于业务;

    用户中心:主要管理用户核心领域,变动不大,需稳定高可用的服务;

    鉴权授权中心:变动不大,主要管理用户凭证核心领域;

服务设计思考:平台化

  1. 抽离通用功能。

    那些非业务的通用功能应隔离于业务之外: 组件化工具化服务化

    来源监控接口限流日志分析应用监控服务依赖配置管理系统部署 等(业务人员不必关心这些功能相关的事情,只需要关注于具体的业务领域)。关注点分离。

    如上面所涉及的,从 Spring Cloud 的各大组件可以看出,最终的方案都将走上相近的道路。

  1. 领域上下文划分。划分微服务项目。业务隔离,数据去中心化。服务组件化。

    Spring cloud 技术栈:

    • 服务治理: 注册中心,服务调用,衍生的容错(熔断器)
    • api 网关: 来源监控,接口限流(Spring Cloud gateway、zuul)
    • **配置中心: ** 配置管理(Apollo)
    • 自动化部署: Jenkins、docker、k8s
    • 日志与监控: prometheus、influxdb、skywalking、elk
    • 数据可视化: druid、kylin、superset
  1. 细节管控

    接口版本管理, gitflow 管理,项目迭代 release 版本管理,标准化,敏捷开发。

欢迎关注我的公众号。

服务设计思考:平台化

原文 

http://www.cnblogs.com/WeaRang/p/13160340.html

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 服务设计思考:平台化

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址