1
电子说
微服务架构是一项在云中部署应用和服务的新技术。
架构特征如下:
1)组件以服务形式来提供
微服务是面向服务的
2)围绕业务功能进行组织
微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务是针对业务领域有着完整实现的软件,
它包含使用接口、持久存储以及对应的交互。因此团队应该是跨职能的,包含完整的开发技术--用户体验、数据库和项目管理。
3)产品不是项目
传统的开发模式致力于提供一些被认为是完整的软件,一旦开发完成,软件将移交给维护或实施部门,然后开发组就可以解散了。
而微服务要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都要关注软件产品的运行情况,并与用户联系的更紧密,
同时承担一些售后服务支持。越小的服务粒度越容易促进用户与服务提供商之间的关系。
4)强化终端与弱化通道
微服务的应用致力于松耦合和高内聚,它们更喜欢简单的REST风格,而不是复杂的协议(例如BPEL或集中式框架)。要么采用轻量级
消息总线(如RabbitMQ)来发布消息。
5)分散治理
跟传统的集中式管理有很大区别,微服务把整体式框架中的组件分拆成不同的服务,在构建时将会有更多的选择。
6)分散数据管理
当整体式的应用使用单一逻辑数据库对数据进行持久化时,企业通常会选择在应用的范围内使用一个数据库。微服务让每个服务管理
自己的数据库。
7)基础设施自动化
云计算特别是AWS的发展减少了构建、发布和运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化,毕竟发布工作相当无趣。
8)容错性设计
任务服务都可能因为供应商的不可靠而出现故障,微服务应为每个应用的服务和数据中心提供日常的故障检测和修复。
9)改进设计
由于设计会不断更改,微服务所提供的服务应该能够替换,而不是长久的发展。
随着互联网的高速发展,微服务现在已经成了热门话题,我们今天就来聊聊微服务架构的使用场景,在之前,我们先讲讲单体架构,单体架构就是我们最传统的项目前端代码和后端代码耦合在一起。
单体架构的适用场景
业务场景简单,功能不复杂,研发人员较少。
公司处于创业初期:为了生存,需要的是快速开发出功能,然后到市场上试错。
性能要求及其苛刻:一些对性能要求比较高的系统,例如股票软件。
需求比较稳定的系统也不适合做成微服务,例如:公司内部OA,考勤系统等。
微服务的使用场景
需求层面:
公司发展到一定规模,需求变化频繁,并且研发团队达到10人左右
性能层面:
对响应时间要求不苛刻的系统,比如:电商系统
数据一致性层面:
尽量避免分布式事务问题,对数据一致性不太高可保证最终一致性
微服务的目的
项目快速迭代
项目持续交付
责任编辑:YYX
全部0条评论
快来发表一下你的评论吧 !