架构的演进
在这里插入图片描述
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（）是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架()是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（）是关键。
什么是RPC？
RPC——Remote Procedure Call,远程过程调用。 即服务A调用服务B的方法，那就需要解决如下两个问题：
- 解决分布式系统中，服务之间的调用问题
- 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
在这里插入图片描述
图中Client对应服务A，Server对应服务B
- 1.Service A的应用层代码中，调用了Calculator的一个实现类add()方法，希望执行一个加法运算；
- 2.这个Calculator实现类，内部并不是直接实现具体的加减乘除逻辑，而是通过远程调用Service B的RPC接口，来获取运算结果，因此称为
；
- 3.Stub怎么和Service B建立远程通讯呢？这时候就要用到
了，也就是图中的
，这个工具将帮你实现远程通讯的功能，比如Java的Socket，当然也可以使用
，或者其他的。--
。
- 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的实际实现类去执行。很明显，如果是
，那这里肯定用到了
。
- 8.RPC接口执行完毕，返回执行结果，现在轮到Service B要把数据发给Service A了，怎么发？一样的流程，只是现在Service B变成了Client，Service A变成了Server而已：Service B序列化执行结果->传输给Service A->Service A反序列化执行结果->将结果返回给Application。
RPC--参考资料
RPC和REST区别
RPC
在这里插入图片描述
REST
在这里插入图片描述
在微服务设计中，一个服务A如果访问另一个Module下的服务B，可以采用HTTP REST传输数据，并在两个服务之间进行序列化和反序列化操作，服务B把执行结果返回过来。
由于在应用层中完成，整个通信的代价较高，远程过程调用（RPC）中直接基于
进行远程调用，数据传输在传输层TCP层完成，更适合对效率要求比较高的场景，RPC主要依赖于客户端和服务端之间建立Socket链接进行，底层实现比REST更复杂。
延伸：dubbo基于TCP，spring cloud Feign基于HTTP
Spring Cloud Feign--参考资料
GRPC--类似dubbo的调用过程了
在这里插入图片描述
RPC、REST、GRPC比较--参考链接
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时提高机器利用率的资源调度和治理中心（）是关键。
SOA
SOA（Service Orientd Architecture）“面向服务的架构”--是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
架构特点
- 系统集成--站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构、梳理成规整、可治理的系统间星系结构，这一步往往需要引入一些产品，比如ESB、技术规范、服务管理规范等。解决的核心问题--
- 系统的服务化--站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。解决的核心问题--
- 业务的服务化--站在企业的角度，把企业职能抽象成可复用、可组装的服务。把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”，这里则是以业务驱动把一个业务单元封装成一项服务，解决的核心问题--
微服务架构
微服务架构--其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
架构特点
- 通过服务实现
--开发者不再需要协调其他服务部署对本服务的影响。
- 按
来划分服务和开发团队--开发者可以自由选择开发技术，提供API服务。
-
--每个微服务有自己私有的数据库持久化业务数据
--每个微服务只能访问自己的数据库，而不能访问其他服务的数据库
--某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其他微服务的数据库，而是通过对于微服务进行操作。
--数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。 - ▪ 基础设施
（devops、自动化部署）
--Java EE部署架构，通过展现层打包WARS，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器的数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些非服务基于业务能力构建，能实现集中化管理
主要区别
在这里插入图片描述
网友评论