dubbo发展背景——引申其他概念

架构的演进

单一应用架构

  当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。

垂直应用架构

  当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

分布式服务架构

  当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。

什么是RPC？

  RPC——Remote Procedure Call,远程过程调用。 即服务A调用服务B的方法，那就需要解决如下两个问题：

• 解决分布式系统中，服务之间的调用问题
• 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。

  图中Client对应服务A，Server对应服务B

• 1.Service A的应用层代码中，调用了Calculator的一个实现类add()方法，希望执行一个加法运算；
• 2.这个Calculator实现类，内部并不是直接实现具体的加减乘除逻辑，而是通过远程调用Service B的RPC接口，来获取运算结果，因此称为Stub；
• 3.Stub怎么和Service B建立远程通讯呢？这时候就要用到远程通讯工具了，也就是图中的Run-Time-Library，这个工具将帮你实现远程通讯的功能，比如Java的Socket，当然也可以使用基于Http协议的HTTPClient，或者其他的。-- RPC并没有规定要用何种协议进行通讯。
• 4.Stub通过调用通讯工具提供的方法，和Service B建立了通讯，然后将请求数据发给Service B。需要注意的是，由于底层的网络通讯是基于二进制格式的，因此这里Stub传给通讯工具类的数据也必须是二进制，比如calculator.add(1,2)，你必须把参数值1和2放到一个Request对象里面（这个Request对象还包括调用哪个服务的哪个RPC接口等其他信息），然后序列化为二进制，再传给通讯工具类。
• 5.二进制的数据传到Service B这边了，Service B当然也有自己的通讯工具，通过这个通讯工具接受二进制的请求；
• 6.既然数据是二进制的，那么自然要进行反序列化了，将二进制的数据反序列化为请求对象，然后将这个请求对象交给Service B的Stub处理；
• 7.和之前的Service A的Stub一样，这里的Stub也同样是个“假玩意”，它所负责的，只是去解析请求对象，知道调用方要调的是哪个RPC接口，传进来的参数又是什么，然后再把这些参数传给对应的RPC接口，也就是Calculator的实际实现类去执行。很明显，如果是Java，那这里肯定用到了反射。
• 8.RPC接口执行完毕，返回执行结果，现在轮到Service B要把数据发给Service A了，怎么发？一样的流程，只是现在Service B变成了Client，Service A变成了Server而已：Service B序列化执行结果->传输给Service A->Service A反序列化执行结果->将结果返回给Application。

RPC–参考资料

如何给老婆解释什么是RPC
如何实现一个简单的RPC

RPC和REST区别

RPC

REST

  在微服务设计中，一个服务A如果访问另一个Module下的服务B，可以采用HTTP REST传输数据，并在两个服务之间进行序列化和反序列化操作，服务B把执行结果返回过来。

  由于Http在应用层中完成，整个通信的代价较高，远程过程调用（RPC）中直接基于TCP进行远程调用，数据传输在传输层TCP层完成，更适合对效率要求比较高的场景，RPC主要依赖于客户端和服务端之间建立Socket链接进行，底层实现比REST更复杂。

延伸：dubbo基于TCP，spring cloud Feign基于HTTP

Spring Cloud Feign–参考资料

Spring Cloud 之 Feign

GRPC–类似dubbo的调用过程了

RPC、REST、GRPC比较–参考链接

什么是RPC

流动计算架构

  当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时提高机器利用率的资源调度和治理中心（SOA）是关键。

SOA

  SOA（Service Orientd Architecture）“面向服务的架构”–是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。

架构特点

• 系统集成–站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构、梳理成规整、可治理的系统间星系结构，这一步往往需要引入一些产品，比如ESB、技术规范、服务管理规范等。解决的核心问题–有序
• 系统的服务化–站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。解决的核心问题–复用
• 业务的服务化–站在企业的角度，把企业职能抽象成可复用、可组装的服务。把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”，这里则是以业务驱动把一个业务单元封装成一项服务，解决的核心问题–高效

微服务架构

  微服务架构–其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

架构特点

• 通过服务实现组件化–开发者不再需要协调其他服务部署对本服务的影响。
• 按业务能力来划分服务和开发团队–开发者可以自由选择开发技术，提供API服务。
• 去中心化
  –每个微服务有自己私有的数据库持久化业务数据
  –每个微服务只能访问自己的数据库，而不能访问其他服务的数据库
  –某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其他微服务的数据库，而是通过对于微服务进行操作。
  –数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
• ▪ 基础设施自动化（devops、自动化部署）
  –Java EE部署架构，通过展现层打包WARS，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器的数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些非服务基于业务能力构建，能实现集中化管理

主要区别

SOA–参考链接

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