1.1  SOA和微服务到底是什么关系

SOA和微服务到底有什么本质上的区别，两者都是对外提供接口的一种架构设计方式。

微服务其实就是随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通过化程度发展，就成了所谓的微服务了。以这种说法做为根据，SOA与微服务的区别在于如下几个方面：

微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；

微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；

微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

1.2  为什么要用微服务

1.2.1  单体架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

单体架构的标志：一种将所有功能打包在一个容器中运行。常见的容器有Tomcat。

Tomcat是什么：是一个软件，在一台机器上配置好tomcat，可利用它响应对HTML网页的访问请求。

此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

1.2.2  垂直应用架构（属于单体架构）

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

比如MVC架构：

MVC是Model，View，Controller的缩写。

Model：模型（数据），模型和数据库中的字段是对应的。

View：界面显示，在屏幕上的展示

Controller：业务逻辑

缺点：

1、相同的业务逻辑代码需要不断地复制，不能复用，造成代码臃肿，复杂性高。

2、每次功能的变更或缺陷的修复都会导致重新部署整个应用。

1.2.3  分布式服务架构

当一个项目业务越来越多，整个项目包含的模块非常多、代码混乱地堆砌在一起。整个项目非常复杂。直接的结果是：每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个bug都会带来隐含的缺陷。

所以，将不同的服务抽取出来，作为独立的服务，每个服务单独部署在一个容器/服务器中，每个服务关注于自己的功能实现，且可以单独扩展升级。

同时我们希望：

不同的服务之间可以进行交互，相同的逻辑可以复用。比如A服务实现了画图功能，B服务需要实现画图功能时，无需复制代码，只需调用A服务即可。

限制因素：

分布式部署时，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

此时，分布式服务框架(RPC)可以解决以上问题：

RPC服务框架提供和本地方法调用一样的调用机制，这样可以简便地将你的应用分布在多台应用服务器上，应用程序就像运行在一个多处理器的计算机上一样。我们可以方便的实现过程代码共享，提高系统资源的利用率。

1.2.4  SOA架构

当服务越来越多，多到你会担心以下问题时，需要增加一个调度中心，基于访问压力实时管理集群容量，提高集群利用率。

1、某个服务可能会有安全访问问题；

2、各个服务容量的评估困难；

3、服务对系统资源的浪费等问题逐渐显现。

此时我们可以使用SOA来解决以上问题，SOA架构具备以下特点：

1、SOA负责系统资源调度管理（注册中心负责资源调度管理）；

2、服务/接口访问管理（ESB企业总线负责服务/接口管理）；

3、通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。1、资源调度管理。（粗粒度应用组件：在金融企业IT架构中，我们可以把短信平台看成一个粗粒度的应用组件。）

1.3  理想中的微服务架构

理想中微服务架构至少有如下几个/特点：

1、 能支持当前业务需求，当然这只是最最基本的条件；

2、每个微服务都要去中心化，不存在单点故障；

3、每个微服务都要实现高可用、高负载，不会因为一个服务不可用而影响了整套业务流；

4、每个微服务都要高度通用化，即多种终端都可调用，不分语言和平台；

5、服务部署或升级简单，不会消耗大量人力并且部署过程不易出现人为错误；

6、微服务具有快速注册与自动发现功能（例如dubbo框架）。

对比解释如下：