云平台实践中的微服务设计原则
以下设计原则是在云平台架构实践(参考这里)中的一些经验总结,不一定适合所有微服务架构的体系。
业务原则
- 单一责任原则:对于一个微服务而言,具有有限的业务范围,可以帮助我们满足服务开发和交付的敏捷性;
- 适当的边界:关注微服务的范围,而不是一味的把服务做小。一个服务的大小应该等于满足某个特定业务能力所需要的大小;
- 业务分层: 先把业务分层,形成单向依赖,避免微服务之间的网状依赖关系;
- 颗粒度递增:初期先把业务划分到尽可能细,然后依据其它原则合并到适当颗粒度;
- 非唯一依赖:至少被2个以上其它微服务依赖,才有必要独立成一个微服务。
技术原则
- 部署独立性:能独立于其它微服务部署,一个微服务故障不影响其它微服务;
- 动态扩展:每个微服务都可以动态的进行x轴和z轴的扩展,并适应云环境下的自动化部署;( 参考这里 )
- 领域和应用分层: 提供数据基本操作能力的领域服务层和执行业务逻辑的应用服务层解耦;
- 避免产生频繁的跨库查询;
- 避免产生频繁的分布式事务。
治理原则
- 根据业务和技术分层的情况,对微服务分组治理;
- 各个分组之间通过API网关集成;
- 通过API网关实现级轻量级消息路由,鉴权;
- 运行时管理,如性能,限流,监控等可在API网关实现,让微服务功能纯粹;
- 避免通过数据库集成;
- 避免部署多个版本来兼容。
相关资料
你现在的气质里,藏着你走过的路,读过的书,爱过的人。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
面向网络转型的编排管理系统和ONAP自研产品介绍
背景 网管系统通过对网络资源、故障、性能的动态监控,实现网络运行的优化管理及运维支撑,是移动通信网络正常、高效运行的重要保障。网管系统经历了“厂家OMC->专业网管->4+1综合网管”的发展历程,解决了跨专业跨厂家进行网络管理的问题,全面支撑各类移动业务、集客业务、家庭宽带业务、新业务。 随着网络新技术,尤其是NFV/SDN的引入,打破了电信行业原有的“黑盒化”封闭系统,降低了电信准入门槛,有利于打造更具活力的生态系统,从根本上改变了CT的发展生态。 一方面,充分解耦后的碎片化网络对运营商的管理和运维带来了巨大的挑战,这需要依赖于新型的管理系统。 另外一方面,NFV给网络带来极大的灵活性和敏捷性,但是网络的灵活性和敏捷性的实现依赖于新的管理系统和自动化编排系统。NFV体系中,全新的管理和编排系统MANO(NFV Management and Orchestration)系统引入,编排器(Orchestrator)作为其中的核心部件,是网络灵活调整和资源动态调度的关键,是下一代网管系统的核心。 随着运维的变革以及IT技术本身的发展,未来网管系统应具备“闭环自动化、灵活的业务定...
- 下一篇
【微服务】分布式事务的实现方法及替代方案
这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC), TCC补偿型提交, 基于消息的异步确保型, 最大努力通知型. 通常对本地事务采用刚性事务, 分布式事务...
相关文章
文章评论
共有0条评论来说两句吧...