SOA在早些年被提出来，是一种面向服务的架构。由于其比较厚重，一般只在大公司有一些落地。在这几年微服务的概念又被提了出来，而且非常火热。SOA与微服务都提到了服务，那么二者有什么区别呢？
SOA核心概念
如上图，SOA将服务拆分，拆分的力度较大，拆分的目的是为了服务的共享。整体对外提供服务的是业务服务，而业务服务的能力是通过编排企业服务达到的。企业服务又会编排应用服务，应用服务实现自身能力的时候又会调用基础服务。这样的架构也会导致这样的组织结构。这些不同类型的服务分别又不同的团队负责开发。SOA的一个显著特点就是平台中间件的存在，也称为EBS。平台中间件在SOA中比较厚重。为了整合这些服务，需要平台中间件进行粘合。平台中间件一般会提供这些能力：1.协议的转化。一般SOA里面的服务所使用的协议是多样的。比如一边是json，一边是xml，又比如一边提供http服务，一边提供rpc服务。对于协议的转换可以做到平台中间件里面。2.服务的路由。有些平台中间件提供服务的注册，实现服务发现。在A服务调用B服务的时候，中间件可以根据负载或者实例的健康状况选择服务。3.可以集成一些如熔断等能力。4.可以实现鉴权或者敏感信息的过滤等。平台中间件的厚重性也是很多公司放弃SOA的原因。但是对于非常复杂的企业应用，SOA还是很有用处的。
微服务架构
从上图发现微服务的架构要简单得多。这也是很多人钟爱微服务的原因。拆分好的微服务一般比较小，三个人左右就可以负责一个微服务。微服务的原则是“能不共享就不共享”，与SOA的“能共享就共享”的原则正好相反。正是因为微服务的独立性，所以微服务可以被独立部署，可以快速启动，可以使用异构的技术，可以快速重构。也是因为独立性的原因，一般微服务会违背“DRY”，会有一些重复代码散落在不同的服务中。另外，因为拆分服务的时候，数据库也是要被拆分的，所以也会存在一部分数据的冗余。在微服务架构中的API网关并不是SOA架构中的EBS。API网关要轻量很多。我们提到微服务，常常把“微”作为核心特点。在真正拆分服务的时候，也要注意，按照业务边界拆分，不能过于“微”。因为服务过细，就会意味着服务数量很多，服务的依赖和交互就会很复杂，运维也很痛。另外，如果出现为了响应一次请求需要A调用B，B调用C，C调用D，D调用E的情况，那么可能你的服务拆分得可能过于细了或者服务的边界找错了。过长的调用链会导致性能的下降，毕竟增加了那么多次网络交互。还有一种情况就是，当你发现实现事务非常困难的时候，把涉及事务的几个服务合到一起也许是个好主意。
上面简单得对比了一下SOA与微服务的差别，后续的文章会继续介绍如果构建微服务，包括API网关的构建、服务发现、故障隔离、跨服务事务等。欢迎大家持续关注~~
閱讀更多 java技術小碼農 的文章
