SOA 架构和微服务Dubbo架构的区别及优缺点 - 好文

<>1. 传统系统架构和微服务架构

传统的系统架构是单一架构模式。这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring
boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包。

微服务架构则是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

<>2. SOA 架构和微服务架构的区别

面向服务架构（SOA）已经存在有些年头了，这是一种用于设计软件的伟大原则。在SOA中，所有组件都是独立自主的，并能为其他组件提供服务。

SOA 微服务构架
应用程序服务的可重用性的最大化专注于解耦
系统性的改变需要修改整体系统性的改变是创建一个新的服务
DevOps和持续交付正在变得流行，但还不是主流强烈关注DevOps和持续交付
专注于业务功能重用更重视“上下文边界”的概念
通信使用企业服务总线ESB 对于通信而言，使用较少精细和简单的消息系统
支持多种消息协议使用轻量级协议，例如HTTP，REST或Thrift API
对部署到它的所有服务使用通用平台应用程序服务器不是真的被使用，通常使用云平台
容器（如Docker）的使用不太受欢迎容器在微服务方面效果很好
SOA服务共享数据存储每个微服务可以有一个独立的数据存储
共同的治理和标准轻松的治理，更加关注团队协作和选择自由
<>3. 传统单一构架的缺点

1.不再使用敏捷开发，过于复杂，任何开发者都不能够完全理解，修复漏洞和实现新功能变得困难和耗时。
2、规模越大，启动时间越长，自然会拖慢开发进度，一个小功能的修改部署起来变得困难，必须重新部署整个应用。
3、系统的不同的模块的需要不同的特定的虚拟机环境时，由于是整体应用，那么只能折中选择。
4、任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性。
5、还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。

<>4.采用微服务架构模式优点

1、由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。
2、每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。
3、整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。

4、一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。每个后端服务暴露一套REST
API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。以上介绍的微服务架构模式表面上类似于SOA，两种架构都包含一组服务。可以认为微服务架构是不包括Web服务规范（WS-）、企业服务总线（ESB）的SOA。基于微服务的应用倾向于使用更简单轻量级的协议，比如
REST 而不是 WS-。微服务自己实现类似 ESB 的功能并且拒绝 SOA 的其他部分（例如：规范模式）。

<>5.微服务架构缺点

1、微服务应用作为分布式系统带来了复杂性。各个微服务进行分布式独立部署，当进行模块调用的时候，分布式将会变得更加麻烦。
2、微服务架构一般使用各个独立数据库，分布式事务的实现更具挑战性。
3、测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。
4、部署基于微服务的应用也很复杂，独立微服务的部署不但变得复杂，而且需要更高级别的自动化。

热门工具换一换