标签：SOA dubbo 功能 服务 演变 系统 应用 架构

架构演变：

1. 单体应用

All in one ，一个系统包含所有的功能。项目比较大。eg：一个商城系统，系统中包含了很多功能，订单功能，用户功能，物流功能，购物车功能。

1. 刚开始，打成一个war包，部署服务。网站访问量小，流量少，完全可以支撑。

2. 随着流量越来越多，已经不足以支撑流量，我们需要进行优化和扩展单体应用。怎么扩展呢。

   分为水平扩展和垂直扩展:

水平扩展：就是多搞几台机器，多部署几台机器，起到分流的作用。

垂直扩展：对于硬件来说就是换更厉害的机器。换牛逼的cup，硬盘等，但是这些终究是有限的。那们硬件不行，我们就来软件的。将应用拆分为互不相干的几个应用，每个应用都是一个小型的单体应用。前端 后端 数据库一应具全。也就是所谓的烟囱架构，各个应用想烟囱一样，彼此独立。这就是垂直应用架构。

2. 垂直应用架构

烟囱架构：

既然垂直应用架构是要进行系统拆分，那就是将一个大型的系统拆分成几个小的系统。其实说白了就是将大的单体应用拆分成 多个小的单体应用。这几个单体应用需要互不相干。既然互不相干就是说明每个系统能够独立的运行。所以在拆分系统的时候要注意。

信息孤岛：

eg：将商城系统拆分成订单系统，物流系统，但是订单系统和物流系统都会依赖于用户功能，所以需要在这两个子系统都实现用户模块的功能。所以用户功能相当于重复了。而且订单系统里的用户信息和物流系统里的用户信息还不能共享，这就是所谓的信息孤岛

但随着垂直应用的增多，重复功能的增多，难免需要系统之间的交互。所以也需要一种架构避免这种重复性的情况。而且前后端不分离，每次修改，都需要整个系统进行部署，所以提出分布式应用架构。

这里的框架是 mvc框架，ssh（struts+spring+heberneter），ssm（spring mvc+spring+mybaits） 等

3. 分布式架构

分布式架构包含范围很多，分布式应用、分布式网络、分布式数据库、分布式存储等。

而我们所说一般都指的是分布式应用。当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。也就是说我们将垂直架构中每个单独的系统再次拆分，前后端分离等，抽取出公共的服务等。

SOA架构是分布式架构的实现，面向服务编程架构（Service-Oriented Architecture），但是SOA提出后，真正落地实施是ESB的实现和RPC的实现。SOA将系统拆分成多个服务系统，或者服务平台，通过服务之间的相互依赖和组合共同实现系统功能。

eg：以上的商城系统，就可以拆分成订单系统，用户系统，物流系统，或者如果还需要一些文件的上传下载，可以开发一个文件服务平台，订单系统依赖用户系统，物流系统依赖用户系统，三个系统都依赖文件平台，然后前后端分离，依赖，组合各种服务实现整个商场功能功能。

3.1 SOA架构

SOA的两种实现方式：

webService+esb总线 和 微服务架构

1. webService+esb总线就能实现整体功能。一般用于企业中一些大型项目系统的框架
2. 微服务架构算是SOA的升级版，如果说SOA专注于将系统服务化和分散化，那么微服务更专注于将服务精细化和专业化，认为业务需要彻底的组件化和服务化。一般用于网络电商的框架。

3.2 微服务架构

微服务，微就是细小，就是在SOA的基础上将服务拆分的更细更小。

微服务架构目前主流的框架支持是dubbo 和 Spring cloud

dubbo使用RPC协议

spring cloud RustFul的http协议

而dubbo框架目前有两种看法：

1. 认为dubbo算是SOA的一种实现，和webService+esb归为一种
2. 任务dubbo属于微服务的一种

3.3 soa 和微服务的比较

soa的特点：

优点：
　　　　抽取公共的功能为服务,提高开发效率，保证可重复性
　　　　对不同的服务进行集群化部署解决系统压力，保证高效性
　　　　基于ESB/DUBBO减少系统耦合，并且能够对所有服务系统进行整理和统一规划，ESB的使用，保证有序性
　缺点：
　　　　抽取服务的粒度较大
　　　　服务提供方与调用方接口耦合度较高

微服务的特点：

优点：

（1）解耦，根据功能将系统分为不同的独立运行的服务，拆分的更细更小，将原来的复杂的系统简单化，每个服务交付给不同的团队去负责，提高了开发效率。开发人员可以只关注自己的业务功能。
（2）容错性高，将错误隔离在单个服务内。
（3）技术选型灵活，不同的服务可以根据自己的需求选择不同的技术。
（4）易于扩展，可以按需扩展服务，避免资源的浪费
（5）独立部署，每个服务独立部署，当其中一个服务有需求变更时，可以只编译部署单个应用，减少了对用户的影响

缺点：（1）开发人员需要面对分布式系统的复杂性。测试更加困难，需要保证服务之间的通信；需要团队之间的协调；当用例涉及到多个服务的时候，需要实现分布式事务管理。
（2）部署比较复杂。不过现在已经提供了自动化部署的工具。
（3）增加内存开销，微服务系统用多个服务实例取代了传统垂直架构的单个服务实例。有多少服务实例，就会有多少在内存运行的开销。

区别：

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

标签：SOA,dubbo,功能,服务,演变,系统,应用,架构
来源： https://blog.csdn.net/tzw1039911355/article/details/120585895

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。