开发者学堂课程【基于 Zookeeper、Dubbo 构建互联网分布式基础架构：互联网基础架构演进（3）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/635/detail/10159
互联网基础架构演进（1）
内容介绍
一、传统垂直 mvc 项目
二、RPC架构
一、传统垂直 mvc 项目
1.垂直架构图
垂直架构项目：
比如像 cim oa 等访问量比较少，用户量没有那么多的项目。
优点：各个层都在一个图里，简单，清晰，明了。
缺点：当项目不断演进时，应用规模越来越大，问题越来越凸显，比如
1) 复杂应用的开发维护成本变高部署效率逐渐降低一个功能出问题，整个系统就得重新打包。
2) 团队协作，效率，变差公共功能，重复开发代码重复率太高。
3) 系统可靠性变差流量负载均衡数据库压力变大，因为在一个进程中，如果出现内存一出的故障，将导致整个节点崩溃，然后集群中的其他几点也会如此。
4) 维护和定制困难，无法随时拆分，修改一处，牵一发而动全身。
5) 新功能上线周期变长，因为公共功能的变更，导致测试工作量集中，因为重复代码，一个地方修改需要同时修改多个地方，然后修改后继续测试新功能无法独立打包测试需要和一整个系统进行打包测试出现 bug 会导致整个系统重新部署抢，强耦合导致效率低下。
二、RPC 架构
RPC是远程过程调用（Remote Procedure Call）的缩写形式。它是一种通过网络从远程计算机程序上请求服务而不需要了解底层网络技术的协议。
SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。
RPC 协议假定某些传输协议的存在，如 TCP 或 UDP 为通信程序之间携带信息数据在OSI网络通信模型中，RPC跨越了传输层和应用层．RPC 使得开发包括网络分布是多程序在内的，应用程序更加容易，采用客户机服务器模式，请求程序就是一个客户机，而程序提供程序就是一个服务器。
首先，客户机调用进程发送一个有定成参数的掉用信息到信息服务进程，然后等待应答信息，在服务器端进程保持睡眠状态，直到调用信息到达为止。当一个屌用信息到达服务器获得进程，仓鼠计算结果发送答复信息，然后等到下一个调用信息，最后是客户端调用进程，接收答复信息获得进程结果，然后调用执行继续进行1、RPC 分为三部分
服务提供者：运行在服务器端，提供服务接口定义和服务实现类。
服务中心：运行在服务器端负责将本地服务发布成远程服务管理，远程服务提供给服务消费者使用。
服务消费者：运行在客户端通过远程代理对象，调用远程服务。
2、RPC 的核心技术点
1)远程服务提供者需要以某种形式提供服务的调用相关信息，包括但是不限于服务接口定义，数据结构，或者中间态的服务定义文件服务调用者需要通过- -定的途径获取远程服务的调用相关信息，例如接口的定义jar包等。
2) 远程代理对象:服务调用者调用的服务实际是远程服务的本地代理,对于java而言,他的实现就是jdk 动态代理，通过动态代理拦截机制,将本地调用封装成远程服务调用。
3) 通信: RPC 框架与具体的协议无关，只要双方遵从约定好的即可，比如可以是 http invoke, 可以是 rmi invoke,也可以是其他任意的二进制压缩协议。
4) 序列化:远程通信，需要将对象转换成二进制数据进行网络传说，不同的所以需要将数据序列化，不同的序列化框架支持的数据类型,数据包大小，异常类型或者性能都不同。
不同的 PC 框架针对的场景不同，因此技术选择也各不相同，-些框架支 持多种序列化框架，甚至支持用户自定义序列化框架
3. RPC 框架的问题
在大规模服务化之前，应用可能只通过RPC框架简单的暴露和引用远程服务,通过配置的ur1地址进行远程调用,路由通过F 5硬件负载均衡进行简单的负载均衡。
当服务越来越多,服务的ur1越来越多,管理越来越困难,负载均衡单点压力变大，此时需要一个服务的注册中心 ,动态的注册和发 现服务,使服务位置透明， 消费者在本地缓存服务提供者列表，实现软负载均衡，可以降低对FS硬件负载的依赖，降低硬件成本。
随着业务的发展,服务间的依赖关系变的错综复杂,甚至分不清哪个应用需要在哪个应用之前启动，需要一个分布式消息跟踪系统可视化战士服务调用链,用于以来分析,业务调用路径梳理，防止服务架构腐化服务的调用量越来越大，服务的容量问题就出现了某个服务需要多少机器支撑,什么时候该加机器服务。
上线容易下线难,上线的审批，下线的通知，需要统一的服务生命周期管理流程进行管控,不同的服务安全权限不同，如何保证敏感数据服务不被误用，服务的访问安全策略如何定制。
服务化后随之而来的就是服务治理问题，纯粹的RPC框架服务治理能力都不强悍,需要通过服务框架+服务治理来完成。
4．常用的 rpc 框架
1. Thrift;
2. Hadoop的Avro-RPC;
3. Hessian;
4. gRPC;
单论 rpc 的话，没太多可说的，可是如果加上服务治理，那复杂度就几何倍数增长了。服务治理里面东西太多了，动态注册，动态发现，服务管控，调用链分析等等问题这些问题，单凭rpc框架解决不了，所以现在常用的说的服务化框架，通常指的是rpc+服务治理2个点。
SOA 服务化架构
微服务
MSA也是一-种服务化架构风格，正流行ing，服务划分
1.原子服务，粒度细;
2.独立部署,主要是容器;
MSA 与 SOA 的对比:
服务拆分粒度: soa 首要解决的是异构系统的服务化，微服务专注服务的拆分，原子服务;
服务依赖: soa 主要处理已有系统，重用已有的资产，存在大量服务间依赖，微服务强调服务自治，原子性，避免依赖耦合的产生;
服务规模: soa服务粒度大，大多数将多个服务合并打包，因此服务实例数有限，微服务强调自治，服务独立部署，导致规模膨胀，对服务治理有挑战;
架构差异:微服务通常是去中心化的，soa 通常是基于 ESB 的; !
服务治理:微服务的动态治理，实时管控，而soa通常是静态配置治理;
交付:微服务的小团队作战。
感觉在有了 docker 后，微服务这个概念突然火了起来，总结就是微服务+容器+DevOps.
