软件架构---微服务架构

Posted sdysyhj

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件架构---微服务架构相关的知识,希望对你有一定的参考价值。

我们可以将微服务架构(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个服务节点部署,还涉及到部署后的配置,扩展和监控问题。
 
参考:
链接:https://www.zhihu.com/question/37808426/answer/225709062
链接:https://www.zhihu.com/question/37808426/answer/90979979
来源:知乎
参考:http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

以上是关于软件架构---微服务架构的主要内容,如果未能解决你的问题,请参考以下文章

微服务架构图

软件架构设计学习总结(22):软件架构——分层架构事件驱动架构微内核架构微服务架构基于空间的架构

Scala微服务架构 一

学习笔记:《微服务架构设计模式》之服务的拆分策略

技术干货 | 微服务架构软件的持续集成与交付

软件架构---微服务架构