参考文章：
https://blog.csdn.net/timo1160139211/article/details/79272304/
1、背景
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有
条不紊的演进。
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
2、框架分类
首先了解什么是RPC，为什么要用RPC
RPC(Remote Procedure Call Protocol)是B指远程过程调用，也就是说两台服务器A，B，一个应用部署在A上想要调用B服务器应用提供的函数方法，由于不在一个内存空间，不能直接进行调用，，需要通过网络来表达调用的语义和传达调用的数据。
如
Girl callMMGirlByName( String name)
那么，首先要解决通讯的问题，主要是通过在客户端和服务器之间建立Tcp连接，远程过程调用的所有交换的数据都在这个连接里传输。
第二，要解决寻址的问题，也就是说A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议的RPC，就要提供一个endpoint URI,或者是从UDDI服务上查找（web service 中具体用用了rpc框架）
第三，解决参数传递的问题，当 A服务器上的应用远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器 ，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，通过寻址和传输将序列化的二进制发送给B服务器。
第四、B服务器收到请求后，需要对参数进行反序列化，恢复成内存中的传递方式，然后找到对应的方法进行本地回调，然后得到返回值
第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达式
以一个公司为例：
有基层员工 有管理层 有老板，最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转；
上述就是我理解的SOA的概念
