单体架构-->SOA架构
image.png
单体架构基本上就是如上所说的：一个应用，一个数据库，一个web容器，里面集成了所有的功能。
这在小型项目里面时比较好维护的，毕竟功能不多，也不复杂，
但扩展性和可靠性比较差，因为所有功能集成在一个服务或者一个war包中，修改某个功能时，需要所有服务重新打包。
可能前期开发比较快，后期随着功能的增长，交互的周期会越变越长的。
服务化架构，也可以称之为SOA架构。
SOA代表面向服务的架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。
这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。
一般上我们使用dubbo来进行服务的治理功能，没有使用SpringCloud之前，基本上都是使用dubbo来拆分服务，进行服务间的调用。
SOA架构 --> 变迁到 微服务架构
其实服务化架构已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？
先说说它们的区别:
微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。
微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
微服务的切分粒度会更小
ESB企业服务总线
企业服务总线也是SOA的核心构成部分。
要真正实现应用架构完善的SOA结构，简化SOA构件间的关系，就一定要建设好信息系统的企业级服务总线。
企业服务总线(ESB)就是一条企业架构的总线，所有的企业服务都挂接到该总线上对外公布，
企业服务总线负责管理服务目录，解析服务请求者的请求方法、消息格式，并对服务提供者进行寻址，转发服务请求。
说白了，它就是服务的请求者和服务的提供者之间的一个中间件，就是对服务使用者屏蔽服务提供方的技术实现方式。
如果没有这个总线，那么服务的请求者则必须自己知道它所需要的服务的地址，并要知道相应的服务调用方法，消息格式，
这样的调用是点到点的，不利于服务的统一管理，不利于不同格式的服务的集成。
ESB企业服务总线
ESB可以说是搭建SOA架构所必须实现的核心功能组件。
总的来说，它的主要功能和职责是消息解析，验证，服务路由转换，请求的传递，服务目录管理。
ESB使用SOAP消息格式，支持HTTP(S)、JMS、MQ、FTP、SMTP等传输协议。
ESB也可以说是传统中间件技术与XML、Web服务等技术相互结合的产物。
从软件设计的角度上来说，ESB是一个抽象的间接层，提取了服务调用过程中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。
要记住 java编程思想：“所有的软件设计的问题都可以通过增加一个抽象的间接层而得到解决或者得到简化！！！”
Dubbo和Spring Cloud
首先Dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了Spring 、Spring Boot的优势之上，两个框架在开始目标就不一致，Dubbo定位服务治理、Spring Cloud是一个生态。
如果仅仅关注于服务治理的这个层面，Dubbo其实还优于Spring Cloud很多：
Dubbo 支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis 等。
Dubbo 使用 RPC 协议效率更高，在极端压力测试下，Dubbo 的效率会高于 Spring Cloud 效率一倍多。
Dubbo 有更强大的后台管理，Dubbo 提供的后台管理 Dubbo Admin 功能强大，
提供了路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。
可以限制某个 IP 流量的访问权限，设置不同服务器分发不同的流量权重，并且支持多种算法，利用这些功能我们可以在线上做灰度发布、故障转移等
网友评论