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

我们可以将微服务架构（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