SOA和微服务的区别

先讲一讲架构的演变

1.单体架构（集中式架构）

项目功能比较简单，一个项目就需要一个应用，里面有多个模块，所有功能部署在一起，这样的好处是部署节点的成本比较低。

 

 

 缺点：耦合性太强；开发维护困难、无法水平拓展；容错性低，并发能力差。

 

2.垂直拆分架构

访问量变大了，单一的应用服务无法满足需求，为了应对更高的并发和业务需求，就要根据业务对系统进行拆分。

 

 

 优点：

• 实现了流量分担，处理并发请求的能力提高。
• 降低了耦合型，我们再对某个模块进行优化的时候更加方便了。
• 水平扩展变得方便了。
• 容错率提高了。

缺点：

• 会有大量的重复代码，影响开发效率。

 

3.分布式服务

当业务越来越多、越来越复杂时，不只是垂直应用这一条线进行数据调用，可能说，应用之间也会相互调用，可能会为了完成一个业务功能，需要多个小模块之间相互调用。

 

 

 优点：

• 将服务粒度细化，减少了代码的重复率，提高了代码复用率，提升了开发效率。
• 系统之间耦合度变高了，调用关系错综复杂，比较难以管理。

 

4.服务治理架构SOA

当服务越来越多，一些小问题比如容量的评估、小服务的资源浪费问题开始显现出来，这个时候就需要一个服务调度中心基于访问压力实时管理集群容量，提高集群利用率。

 以前分布式服务的问题：

• 服务很多，服务的地址难管理
• 服务过多，服务的状态难以管理，无法根据服务的情况进行管理

SOA服务治理架构的优点：

• 提供一个服务注册中心，实现服务的自动注册与发现，无需人为记录服务地址。
• 服务自动订阅，服务列表自动推送，服务的调用透明化，无需关心依赖关系。
• 动态的监控服务状态，人为控制服务状态。

SOA服务治理架构的缺点：

• 依赖关系是无法避免的，一旦某个环节出错影响较大。
• 服务关系依旧是复杂的，运维、测试、部署困难，不符合开发-运维一站式维护的思想。

 

5.微服务

 

 

微服务的特点：

• 单一职责：一个微服务只对应一个业务能力，也就是粒度很小。
• 微：拆分的粒度小，但是该有的机制都有。
• 面向服务：每个服务都要对外暴露Restful风格的API。但并不关系业务具体是怎么实现的，比如说是用哪种语言写的、在哪个平台开发的。
• 自治：是说服务之间相互独立，互不干扰，不是自我管理。
• 团队独立：每个服务都由一个独立的开发团队完成，人数不宜过多。
• 技术独立：只要实现业务功能，提供restful接口即可，不关心内部的实现逻辑、语言、开发平台。
• 前后端分离：提供统一的restful风格接口，后端不用再为PC、移动端开发不同的接口。
• 数据库分离：每个服务都使用自己的数据源。
• 部署独立：尽管服务间是有调用关系的，但也要做到一个微服务重启不影响其他微服务。有利于持续集成、持续交付。每个服务都是独立的组件，可复用、可替换、易维护。