详解SOA和微服务架构的区别

如果一句话来谈SOA和微服务的区别，那就是微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

微服务架构的定义和阐述

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

微服务架构的特点

1. 对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的。
2. 微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。
3. 微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。

SOA和微服务的区别

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

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

为什么要有微服务架构

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

• 单一应用架构
  当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
  此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
• 垂直应用架构
  当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
  此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
• 分布式服务架构
  当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
  此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
• 流动计算架构
  当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
  此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

平台随着业务的发展从 All in One 环境就可以满足业务需求（以Java来说，可能只是一两个war包就解决了）；发展到需要拆分多个应用，并且采用MVC的方式分离前后端，加快开发效率；在发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，我觉得就可以将之理解为一个微服务了。

单体应用带来的问题

1. 系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身。
2. 运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。
3. 无法扩展：无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是DB问题难解决。

理想中的微服务架构

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

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

当然，这只是其中能想到的几点，实际环境中用到的微服务框架有可能会根据实际业务需求优化出更加个性化的功能，也可能有些功能是不需要的。还是那句话，架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构，才是好的微服务架构。

版权声明：本文为博主原创文章，未经博主允许不得转载。

： » 详解SOA和微服务架构的区别