标签:复杂度 try 企业 升级 question 敏捷开发 性能 微服务 功能
我们可以将微服务架构(microservices architecture)理解为 SOA 的升级。
基于以下相同点:
- 需要Registry,实现动态的服务注册发现机制;
- 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑;
- 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息;
- 都需要统一的Gateway来汇聚、编排接口,实现统一认证机制,对外提供APP使用的RESTful接口;
- 同样的要关注如何再分布式下定位系统问题,如何做日志跟踪,就像我们电信领域做了十几年的信令跟踪的功能;
当问到微服务架构与SOA的区别,我们能找到以下回答:
微服务其核心思想是在应用开发领域,使用一系列微小服务来实现单个应用的方式途径,或者说微服务的目的是有效的拆分应用,实现敏捷开发和部署,而SOA可能包含的意义更泛一些,更不准确一些。
相比SOA,微服务框架将能够带来更大的敏捷性,并为你构建应用提供更轻量级、更高效率的开发。
从服务粒度上,既然是微,必然微服务更倡导服务的细粒度,重用组合,甚至是每个操作(或方法)都是独立开发的服务,足够小到不能再进行拆分。而SOA没有这么极致的要求,只需要接口契约的规范化,内部实现可以更粗粒度,微服务更多为了可扩充性、负载均衡以及提高吞吐量而去分解应用,但同时也引发了打破数据模型以及维护一致性的问题。
服务的切分上有比较大的区别,SOA原本是以一种“集成”技术出现的,很多技术方案是将原有企业内部服务封装为一个独立进程,这样新的业务开发就可重用这些服务,这些服务很可能是类似供应链、CRM这样的非常大的颗粒;而微服务这个“微”,就说明了他在切分上有讲究,不妥协。无数的案例证明,如果你的切分是错误的,那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优势,而会比使用Monolithic有更多的麻烦。
如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。
首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的。
其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。
微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。
优势:
- 扩展性好,各个服务之间低耦合
- 容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
- 容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
- 易于测试,可以单独测试每一个服务
而对于微服务架构的不足,简单总结如下:
1. CAP原则:由于服务无状态和引入了分布式,较难解决事务一致性问题。
2. 集成复杂:任何彻底的分解都将带来集成的复杂度,即模块在集成时候需要外部微服务模块更多的配合
3. 部署问题:稍大项目都涉及到上100个服务节点部署,还涉及到部署后的配置,扩展和监控问题。
参考:
软件架构---微服务架构
标签:复杂度 try 企业 升级 question 敏捷开发 性能 微服务 功能
原文地址:https://www.cnblogs.com/sdysyhj/p/11057824.html