soa与微服务

        微服务是当前比较火热的话题，很多的互联网公司也引入了微服务，我们公司也顺势而为。但是突然有一天，一个朋友问我：“我们系统现在用的是SOA，效果还不错呀，你们公司为什么就改为使用微服务了呢？效果如何呢？”，这个时候我有点不知道从什么角度去回答这个问题，我不能失去这个成长的机会。所以今天将两者分析一下，供大家参考。

        微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

SOA与微服务关系底是什么关系？

        说实话，我确实不明白SOA和微服务到底有什么本质上的区别，两者说到底都是对外提供接口的一种架构设计方式。我倒觉得微服务其实就是随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通过化程度发展，就成了所谓的微服务了。以这种说法做为根据，我觉得SOA与微服务的区别在于如下几个方面：

1. 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响；
2. 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
3. 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

微服务的演进

        技术为业务而生，架构也为业务而出现，当然SOA和微服务也是因为业务的发展而出现。出现SOA和微服务框架与业务的发展、平台的壮大密不可分，下面借用dubbo的网站架构发展图和说明：

单一应用架构

• 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
• 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

垂直应用架构

• 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
• 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

分布式服务架构

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
• 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

流动计算架构

• 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

理想中的微服务

没有什么东西是完美的，网站架构也是这样的，只有「比之前好一点」的架构或「目前最好的实现方式」，不存在理想中的架构，那么理想中微服务架构应该是怎么样的呢，我觉得至少应该有如下几个特点：

1. 能支持当前业务需求，当然这只是最最基本的条件；
2. 每个微服务都要去中心化，不存在单点故障；
3. 每个微服务都要实现高可用、高负载，不会因为一个服务不可用而影响了整套业务流；
4. 每个微服务都要高度通用化，即多种终端都可调用，不分语言和平台；
5. 服务部署或升级简单，不会消耗大量人力并且部署过程不易出现人为错误；

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

 

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