本文转载自微信公众号“飞天小牛”，作者飞天小牛。转载本文请联系飞天小牛公众号。老实说，在我实习之前，我对SOA一无所知。我只听说过微服务。毕竟，微服务如此流行以至于很难不知道。Service，进群后才发现原来是SOA架构。我当时很困惑。看了很多文档，做了很多笔记，但还是不太明白什么是SOA。后来搞不懂SOA和微服务的区别。我什至经历过它。看看这本书?。遗憾的是，由于我刚刚接触SOA，并没有真正尝试过微服务，所以虽然周志明老师写的很简单，但我还是没能理解SOA和微服务的区别。多么真正的区别。这两天看到了一篇IBM的文章，真的很有启发。本文翻译了这篇文章的一些段落，然后根据之前看过的资料，加上一些自己的理解。原文地址在这里，感兴趣的朋友可以自行阅读英文原文：https://www.ibm.com/cloud/blog/soa-vs-microservices什么是SOASOA全称是Service-OrientedArchitecture，一种服务面向架构。请注意，这是一种架构。一开始还以为是和Dubbo一样的框架，hhh，在此请见谅我的无知。SOA是一种**企业范围**的应用软件开发方法，以可重用软件组件或服务的使用为中心。在SOA软件架构中，每个服务都包含执行特定业务功能所需的代码和数据集成。在SOA软件架构中，每个服务都由执行特定业务功能所需的代码和数据集成组成。更通俗地说，SOA就是把系统拆分成大小适中、适合并根据实际业务独立部署的模块，每个模块包含自己需要的代码和数据集，每个模块之间又相互独立。例如，银行网站可能包括检查客户信用、登录网站或处理抵押贷款申请等服务。这三个服务包含与各自业务相关的代码和数据集。从代码层面直观来说，每个服务由以下三部分组成：接口接口：暴露给消费者的接口契约契约：规定服务提供者和服务消费者应该如何交互实现接口实现：SOA中出现的接口的具体实现1990年代后期是应用程序开发和集成演变的重要阶段。在SOA架构起飞之前，将单体应用程序与另一个系统中的数据或功能连接起来需要复杂的点对点集成，一旦出现新项目，开发人员就必须为这个新的开发项目重新创建这些集成。并且通过SOA公开（或共享）这些公共功能，开发人员不需要每次都重写重复的代码。当然，这种方法既有好处也有风险。由于很多应用共享对某个服务的访问，如果这个服务出现问题，这些应用也会受到级联的影响。举个通俗的例子：（来自知乎高赞，稍作修改：广太郎-https://www.zhihu.com/question/42061683）比如现在我有一个数据库，一个JavaWeb网站客户端，一个AndroidApp客户端，一个IOS客户端。现在我想从这个数据库中获取注册用户列表。按照单体应用程序的设计思路，思路是这样的：在JavaWeb中写一个查询方法，从数据库中查询数据并显示在网页上，在AndroidApp中写一个查询方法，查询完后，就会显示在App上，IOS也是一样的。这样，同一套查询方法出现了三次，代码非常冗余，三个地方的业务代码都是一样的。如果要改的话，三个地方都要改，而且改的一定要一模一样。当然问题不仅限于此。于是就有了这样的设计思路，比如用Java（或者其他任何语言）创建一个项目并部署到服务器上，并写一个方法（或函数）来执行上面的查询操作，然后让其他人访问这个method通过一定的方式（可以是HTTP链接，也可以是基于Socket的RPC调用）获取返回的数据。返回的数据类型是一般的JSON或者Xml数据，也就是说把这个查询操作封装到一个项目中。然后暴露这个操作的访问方式，形成一个“服务”（服务接口）。这样JavaWeb就可以访问这个服务，获取数据使用情况，Android和IOS也可以通过这个服务获取数据。而且最重要的是，修改注册用户的业务方法，只需要改这个服务，很好的解耦。同理，商品、广告等其他业务也可以单独形成服务，部署在单独的服务器上。另一种情况是，有一天突然有一群人要注册，假设这群人只是注册，什么都不做，其他业务如商品、广告服务等都不忙，但注册服务很忙压力大，而且原来部署注册服务的服务器已经承受不了这么高的并发了。这时候可以把注册服务部署在一个单独的集群中，多提供几台服务器来提供注册服务，而其他服务不用搬，保持原样即可。当然，上面举的这些例子不能完全称为SOA，也不够完整，因为它缺少了服务治理的环节。什么是服务治理？当服务越来越多，调用者越来越多的时候，它们之间的关系就变得很混乱，需要对这些关系进行管理。还是上面的例子，如果我有一个用户服务，一开始有调用者1和调用者2来使用这个服务，然后越来越多，近百个调用者，此时作为服务端，它只知道提供服务，而不知道服务是为谁提供的。对于开发人员来说，了解N个调用者和N个服务器之间的关系是非常重要的。所以这个时候就需要一个能够进行服务治理的框架，比如Dubbo+Zookeeper，SpringCloud等。有了服务治理的功能，我们就可以清楚的看到这个服务被谁调用了，谁调用了哪些服务，有哪些服务热点服务需要配置服务器集群，而这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。这次是比较完整的SOA。当然，你还可以更进一步，增加服务监控和跟踪等。什么是微服务直接例子：一个在线购物网站会有一些不同的功能，比如产品目录、购物车、下单等。使用SOA的开发公司通常将购物网站拆分为主要的业务逻辑组，并将每个部分作为单独的应用程序单独开发，然后再将它们集成在一起。具体的开发过程包括预先定义好需要暴露给外部调用的服务接口，比如添加购物车操作、下单操作等，然后围绕服务接口进行开发。这样如果火车票模块等其他应用也需要下单，那么直接调用这个服务接口即可。这里大家应该能看出SOA的一个问题，就是围绕主要业务逻辑的划分造成的。所以SOA的粒度比较大。比如我们现在围绕添加购物车和下单这两个主要业务逻辑定义了两个服务接口，但是在添加购物车和下单这两个服务中都有一个比较细粒度的展示商品名称的通用功能order，这样一来，我们就得在这两个服务接口中写一套类似的代码。然而，使用微服务架构的开发公司会将购物车分成更小的面向任务的服务。它不再是购物车应用，而是可能是显示产品名称服务、添加/删除产品服务、运输服务、汇率服务和订单授权服务。购物车功能也可能会用到一些常用的服务——它们会用在整个购物网站的很多地方，比如展示商品名称服务、展示商品图片服务、查看库存服务等等。公共代码被封装到各种服务中，并在需要时用于各种功能。看下面这张网络图，虽然有点看不懂，但是确实很容易理解：图片来源http://blog.sina.com.cn/s/blog_90ad2e8b0102xykv.htmlSOA和微服务的主要区别：作用域相信大家看完上面的例子就能明白了。这两种方法之间的主要区别归结为范围。简单来说，面向服务架构（SOA）的粒度比较大，服务于企业范围，而微服务架构的粒度比较小，服务于应用范围。因此，如果您接受范围上的差异，您可能会很快意识到两者可以潜在地相互补充，而不是竞争。两者相辅相成，而不是竞争。
