33 | 传统的可扩展架构模式：分层架构和SOA

SOA是把多个系统整合，而微服务是把单个系统拆开来，方向正好相反

soa是集成的思想，是解决服务孤岛打通链条，是无奈之举。esb集中化的管理带来了性能不佳，厚重等问题。也无法快速扩展。不适合互联网的业务特点

尝试说下个人浅见: 为什么互联网不用SOA? 1. 互联网企业, 通常比较年轻, 没有那么多异构系统, 技术是公司的关键; 如果有整合或者服务化的需求, 公司有人也有钱专门搞这个; 拆到重做/重构 很平常; 相反的, 传统企业, 举个例子: 某传统炼钢国企 : 有多个遗留.net系统,有几个实习生做的java系统, 有基于数据库procedure的系统; 有各种已经倒闭了的第三方企业的系统 等等; 企业领导不会有精力和想法全部推倒重来, 只会花钱请第三方 , 成本越低越好; 这个时候就需要ESB这种总线 2. 传统企业IT追求的是"需求灵活,变更快", 而互联网企业追求性能, 传统soa 性能不佳 传统的esb ,说实话, 使用webservice 以及soap这种基于xml的技术; wsdl 这东西是真的难用, 难学难用难维护 ; 结构冗杂; 3. soa 这个东西很多时候只是一个概念, 而不是实践 个人觉得, 现在的微服务 , 更像是 soa 思想的一个落地 (相比esb)

一直不明白SOA和微服务的具体区别，知道作者讲到了ESB 的功能，原来就是适配各种协议，顿时明白了!SOA是为了适配老系统。

回答问题:文中也说了，soa是特定历史条件下的产物，为了适配各种异构的it系统，而有如此多系统的自然是变化减少且稳定的传统企业。互联网企业的特点就是小，新，快。没有历史包袱，变化快，大部分是从单体演进到分布式，技术栈一脉相承或者在分布式之前已经从php,ruby等改造到java等了。而到了分布式之后，面对不断的耦合，系统复杂度的陡增，这时一个soa的特例微服务出现了。 实际上soa的思想还在，只不过实现的方式不一样了。

在传统企业从原先的手工作业转为采用IT系统作业的过程中，大多是采用向外采购的方式逐步实现的，在这个过程中不同部门采购系统的实现语言、通信协议并不完全相同，但为提升运行效率又要能够做到企业内部信息互通、相互协作，这是soa诞生的背景。 而互联网企业是新创的企业，没有这么多的历史包袱，同时出于快速迭代的要求，有时会自建所需的系统，即使是对外采购，也会选择和已有系统对接方便的系统，从根本上避免了相关问题，因而soa在互联网公司中使用不多。

soa解决的是资源的重复利用，它的拆分粒度比较大，比如财务系统跟oa系统的员工模块。1.互联网企业有几种情况，1.初创公司，这种公司一般会有试错的过程，需要技术快速实现业务落地，这种情况下使用SOA不适合快速敏捷迭代开发。2.对于成熟的互联网业务来说，需要解决的是是高并发，高性能和高存储等一系列问题，对于这类企业来说，使用SOA拆分不能解决太多问题，还得做更加细粒度的拆分。

SOA更像一种架构理念，不够具体。在传统企业的IT系统中落地为ESB，主要是为了集成异构系统。因为传统企业特别是大型企业的历史长，在其发展过程中自己开发或采购了不少异构系统。 而互联网企业历史都短(腾讯98年，阿里99年，百度2000年)，很少有遗留异构系统(像阿里的系统绝大部分应该都是Java开发的吧？)。像阿里这种互联网大型企业的痛点是随着业务越来越多，整个系统成了个巨无霸(可能是数以千记的模块数)，模块之间的调用像蜘蛛网，极大降低了开发、测试、部署、运维的效率，所以把庞大的业务逻辑层又切分成了业务更独立的应用层和公共功能模块组成服务层。接下来一是要提供应用层与服务层之间、服务层内部服务之间的高效通信机制，二是要对大量的服务进行治理，于是分布式服务框架出现了(阿里就出了Dubbo和HSF两个服务框架？)。感觉在大型互联网企业，SOA实际是落地为分布式服务框架，它更像是微服务架构的一个雏形，服务框架提供的功能实际也是微服务架构里必不可少的功能。

soa主要是为了解决历史遗留问题，引入的esb。而互联网企业都年轻，没有历史包袱，另外互联网企业大部分都需要高性能，而esb可能成为瓶颈。 最后想咨询老师一个问题：在分层结构中。同层能不能互相调用？比如：下单时，需要用户信息，此时应该调用同层用户模块来完成，还是如何处理呢？

其实，个人理解的传统SOA和ESB在互联网企业之所以不怎么使用主要原因就是中心化的ESB架构会逐渐成为性能、可用性、可扩展性的瓶颈。但是SOA的思想本身是没有什么问题的。互联网企业中用的微服务甚至最近很火的Service Mesh都可以看成是SOA、ESB的变形。比如Service Mesh也可以看成是一个去中心化的ESB。