微服务分解原则

业务原则

  • 单一责任原则:对于一个微服务而言,具有有限的业务范围,可以帮助我们满足服务开发和交付的敏捷性;

  • 适当的边界:关注微服务的功能范围,一个服务的大小应该等于满足某个特定业务能力所需要的大小;

  • 业务分层: 从整体规划上把业务分层,形成单向依赖,避免微服务之间的网状依赖关系;

  • 颗粒度递增:设计初期先把业务划分到尽可能细,然后依据其它原则合并到适当颗粒度;

  • 非唯一依赖:至少被2个以上其它微服务依赖的功能模块,才有必要独立成一个微服务。

技术原则

  • 部署独立性:能独立于其它微服务部署,一个微服务故障不影响其它微服务;

  • 动态扩展:每个微服务都可以动态的进行x轴和z轴的扩展,并适应云环境下的自动化部署; 参考这里

  • 领域和应用解耦:提供数据操作能力的领域服务和执行业务逻辑的应用服务解耦;

  • 避免产生频繁的跨库查询;

  • 避免产生频繁的分布式事务。

治理原则

  • 在业务分层的基础上,根据业务细分规则,对微服务分组;

  • 各个分组之间通过API网关集成;

  • 通过API网关实现级轻量级消息路由,鉴权;

  • 运行时管理,如服务降级,限流,监控等可在API网关实现,让微服务功能纯粹;

  • 避免通过数据库集成;

  • 避免部署多个版本来兼容。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。