从 0 到 1 万字贴心讲解单体架构到分布式架构的演变 (第一篇)
其实生活不止眼前的苟且，还有诗和远方。所以我们今天就回顾历史，看一看系统架构演变的历程；把握现在，学习现在最火的技术架构；展望未来，争取成为一名优秀的 Java 工程师。
大家好，给大家先做个自我介绍我是码上代码，大家可以叫我码哥我也是一个普通本科毕业的最普通学生，我相信大部分程序员或者想从事程序员行业的都是普通家庭的孩子，所以我也是靠自己的努力，从毕业入职到一家传统企业，到跳槽未尝败绩，现在在一家某互联网行业巨头公司工作，希望可以通过自己的分享对大家有一些帮助跟随我的专栏学习，可以省去你很多去培训的费用或者网上找资料的时间，节省你的大部分时间成本，让你更加快速成为面试收割机，年度最佳员工
我为大家准备了 16 个技术专栏带领大家一起学习
有什么想学习的技术可以评论区留言，一起进步
很多粉丝反应，想学习分布式系统架构
从这篇码哥将教大家从零开始让你们学会分布式架构中应用场景和解决方案，从实践和理论两方面进行讲解。
记得先点赞，收藏，关注，老铁们一起进步
有什么问题，可以私信我，或评论区留言
0.学习目标
了解系统架构的演变
了解 RPC 与 Http 的区别
掌握 HttpClient 的简单使用
知道什么是 SpringCloud
独立搭建 Eureka 注册中心
独立配置 Robbin 负载均衡
1.系统架构演变
随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到 SOA，以及现在火热的微服务架构，还有在 Google 带领下来势汹涌的 Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？
1.1. 集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
存在的问题：
代码耦合，开发维护困难
无法针对不同模块进行针对性优化
无法水平扩展
单点容错率低，并发能力差
1.2.垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：
优点：
系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高
缺点：
系统间相互独立，会有很多重复开发工作，影响开发效率
1.3.分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
优点：
将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护
1.4.服务治理（SOA）
SOA ：面向服务的架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
以前出现了什么问题？
服务越来越多，需要管理每个服务的地址
调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理
服务治理要做什么？
服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态
缺点：
服务间会有依赖关系，一旦某个环节出错会影响较大
服务关系复杂，运维、测试部署困难，不符合 DevOps 思想
1.5.微服务
前面说的 SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实缺有一些差别：
微服务的特点：
单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
面向服务：面向服务是说每个服务都要对外暴露 Rest 风格服务接口 API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供 Rest 的接口即可。
自治：自治是说服务间互相独立，互不干扰团队独立：每个服务都是一个独立的开发团队，人数不能过多。技术独立：因为是面向服务，提供 Rest 接口，使用什么技术没有别人干涉前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动段开发不同接口数据库分离：每个服务都使用自己的数据源部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护
微服务结构图：
2.远程调用方式
无论是微服务还是 SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下几种：
RPC：Remote Produce Call 远程过程调用，类似的还有 RMI。自定义数据格式，基于原生 TCP 通信，速度快，效率高。早期的 webservice，现在热门的 dubbo，都是 RPC 的典型
Http：http 其实是一种网络传输协议，基于 TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用 Http 协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
现在热门的 Rest 风格，就可以通过 http 协议来实现。
2.1.认识 RPC
RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A 计算机提供一个服务，B 计算机可以像调用本地服务那样调用 A 计算机的服务。
通过上面的概念，我们可以知道，实现 RPC 主要是做到两点：
实现远程调用其他计算机的服务要实现远程调用，肯定是通过网络传输数据。A 程序提供服务，B 程序通过网络将请求参数传递给 A，A 本地执行后得到结果，再将结果返回给 B 程序。这里需要关注的有两点：1）采用何种网络通讯协议？现在比较流行的 RPC 框架，都会采用 TCP 作为底层传输协议 2）数据传输的格式怎样？两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路中传输需要进行序列化，所以还需要约定统一的序列化的方式。
像调用本地服务一样调用远程服务如果仅仅是远程调用，还不算是 RPC，因为 RPC 强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以 RPC 一定要对调用的过程进行封装
RPC 调用流程图：
想要了解详细的 RPC 实现，给大家推荐一篇文章：自己动手实现RPC
2.2.认识 Http
Http 协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用 TCP 协议作为底层传输协议。说到这里，大家可能觉得，Http 与 RPC 的远程调用非常像，都是按照某种规定好的数据格式进行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。
RPC 并没有规定数据传输格式，这个格式可以任意指定，不同的 RPC 协议，数据格式不一定相同。
Http 中还定义了资源定位的路径，RPC 中并不需要
最重要的一点：RPC 需要满足像调用本地服务一样调用远程服务，也就是对调用过程在 API 层面进行封装。Http 协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。优点：RPC 方式更加透明，对用户更方便。Http 方式更灵活，没有规定 API 和语言，跨语言、跨平台缺点：RPC 方式需要在 API 层面进行封装，限制了开发的语言环境。
例如我们通过浏览器访问网站，就是通过 Http 协议。只不过浏览器把请求封装，发起请求以及接收响应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成。
2.3.如何选择？
既然两种方式都可以实现远程调用，我们该如何选择呢？
速度来看，RPC 要比 http 更快，虽然底层都是 TCP，但是 http 协议的信息往往比较臃肿，不过可以采用 gzip 压缩。
难度来看，RPC 实现较为复杂，http 相对比较简单
灵活性来看，http 更胜一筹，因为它不关心实现细节，跨平台、跨语言。
因此，两者都有不同的使用场景：
如果对效率要求更高，并且开发过程使用统一的技术栈，那么用 RPC 还是不错的。
如果需要更加灵活，跨语言、跨平台，显然 http 更合适
那么我们该怎么选择呢？
微服务，更加强调的是独立、自治、灵活。而 RPC 方式的限制较多，因此微服务框架中，一般都会采用基于 Http 的 Rest 风格服务。
个人公众号|码上代码 2020.03.06 加入
码上代码 |CSDNjava领域优质创作者分享
评论