微服务架构的九大特性

1. 服务组件化

       组件,是一个可以独立更换和升级的单元。服务,是通过HTTP等通信协议进行协作,而不是像传统组件那样嵌入式协同工作。因此每个服务都独立开发、部署,可有效避免一个服务的修改引起整个系统的重新部署。

2.按业务组织团队

       在实施微服务架构时,需要采用不同的团队分割方法。由于每一个服务都是针对特定的业务的宽栈或者全栈实现的,既要负责数据的持久化存储,又要负责用户接口定义等各种跨专业领域的职能。因此面对大型项目的时候,对于微服务团队的拆分更加建议按业务线的方法进行拆分,一方面可以有效的减少服务内部修改所产生的内耗,另一方面,团队边界可以变得更为清晰。

3.做“产品”的态度

       在实施微服务架构团队中,每个小团队都应该以做产品的方式,对其产品的整个生命周期负责。

4.智能端点与哑管道    

       由于各个服务不在一个进程中,组件间的通信模式发生了改变,原本进程内的方法调用变成了RPC方式的调用,会导致微服务之间产生烦琐的通信,使得系统表现更为糟糕,所以我们需要更粗粒度的通信协议:

    在微服务架构中,通常会使用一下两种服务调用方法

    (1)使用HTTP的RESTful API或者轻量级的消息发送协议,实现消息传递与服务调用的处触发。

    (2) 通过在轻量级消息总线上传递消息,类似RabbitMQ等一些提供可靠异步交换的中间体。

        【在极度强调性能的情况下,还有可能会使用二进制的消息发送协议,例如protobuf】

5.去中心化治理

        在整个微服务架构,通过采用轻量级的契约定义接口,使得我们队服务本身的具体技术平台不再那么敏感,这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。

6.去中心化管理数据

        在实施微服务架构时,希望每一个服务自己来管理其数据库,这就是数据管理的去中心化,虽然数据管理的去中心化让数据管理更加细致化,让数据存储和性能达到最优,但是不同的数据库实例,数据一致性也成了微服务架构中亟待解决的问题之一,分布式事务本身实现的难度就非常大,所以在微服务架构中,我们更强调各服务之间进行”无事务“的调用,而对数据一致性,只要求数据在最后的处理状态是一致的即可

7.基础设施自动化

       在微服务架构中,务必从一开始就构建起”持续交付“平台来支撑整个实施过程,该平台需要两大内容,缺一不可:自动化测试,自动化部署

8.容错设计

        在微服务架构中,快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的,通常我们都希望在每个服务中实现监控和日志记录的组件。比如:服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

9.演进式设计

        架构师都会以演进的方式进行系统的架构。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值