文章目录
1、系统架构的演进
随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行。下面将用电商系统的演进来举例
1.1 单机架构
Web 应用程序发展的早期，大部分 Web 工程(包含前端页面，web层代码，service层代码，dao层代码)是将所有的功能模块，打包到一起并放在一个web容器中运行，也叫做 All-in-One。
优点：开发简单，适用于小型应用。（配合代码生成工具（mybatis-plus）可以快速开发项目）
缺点：各模块代码紧密耦合，不易扩展、维护
比如早期的电商系统只能卖东西，则系统内包含了：用户、商品、交易业务。
单机架构的问题缺陷（单台机器处理能力有限，高并发下响应速度变慢）：
单机的处理能力有限，只要业务增长到一定程度的时候，单机的硬件资源就会无法满足业务的需求。这个时候就出现了集群架构
1.2 集群架构（单机架构的水平扩展）
把单机系统复制几份，就构成了一个“集群”，集群中每台服务器就叫做这个集群的“节点”。所有节点构成一个集群，每个节点都提供相同的服务，这样我们的系统的处理能力就提高了 N 倍。
在集群架构阶段还出现一个重要的理论：负载均衡
1、当我们有多个相同的节点时，由谁来处理用户发来的请求才显得高效呢？
显然我们挑选此时负载较小的节点来处理请求更加合适，这样每个节点的压力相对平均。要实现这个功能，需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼的名字——负载均衡服务器。
（若集群中某个节点长时间负载过高，而其他节点几乎很少工作时，其实就相当于从集群架构退化到了单机架构。请来的帮手不帮忙）
集群架构的问题缺陷（单台机器带不动多业务的系统）：
集群结构的好处就是系统的水平扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了，也就是说你的系统业务繁重，单台服务器已经带不动这个系统的所有模块了。这时候，就需要对系统进行垂直扩展了。
（换句话说：集群架构也是另类的单机架构，当一个请求涉及到模块A、模块B、模块C时，单机系统自己处理这个请求很慢。所以把一个大的问题拆分为多个小的问题，并分别解决，最终协同合作。分布式的主要工作是分解任务，将职能拆解。）
1.3 垂直应用架构（垂直扩展-将系统按照业务拆分）
将单一的 web 系统按照业务的不同垂直拆分成几个互不通信的独立应用，并且分开部署，来降低单台服务器部署系统的压力。垂直应用架构可以方便的对有需要的系统进行水平扩展（如因为商品的请求压力大，则可以水平扩展商品系统）和提高容错性（如果用户系统出现问题，但是整个项目的商品系统和交易系统还能够正常使用）
将电商系统按照用户业务、商品业务、交易业务拆分成三个子系统，每个子系统可以分别做集群部署。
垂直应用架构的问题缺陷（各不同业务有较多的重复性代码）：
此时系统已经拆分成多个互不通信的业务，有效的降低了单机系统的部署压力。但是业务不同，并不意味着不再进行相同的操作。比如交易业务，其实是需要操作用户信息和商品信息的，此时没有办法调用另外独立的子系统，就只能自己再写出一份重复性代码，当大系统垂直拆分得越来越多，那么各独立子系统之间的重复代码也将会越来越多。
1.4 分布式架构（将业务按照基础服务拆分，达到服务可被各业务共享调用）
当垂直应用（业务）越来越多时，应用之间的交互不可避免，比如随着系统业务的发展，电商系统已经不只是卖东西了，可能还包含了各种广告、营销、后台管理相关的业务。此时根据前面的知识，可以将整个系统垂直拆分为电商业务、CMS业务、后台管理业务。
再接着运用分布式架构的理念，即把业务按照基础服务进行拆分，减少重复性代码，可获得下图所示架构图：
上图中将电商业务拆分为用户服务、订单服务、其他服务，每个服务独立部署，这样用户服务就可以给CMS 业务和后台管理业务共同调用了。减少了很多重复的开发工作，此时还可以通过调用各个服务来迅速完成新业务系统的开发。
分布式架构的问题缺陷（服务太多，导致人工管理服务的成本较高）：
-
服务越来越多，需要管理每个服务的地址和状态
-
调用关系错综复杂，难以理清依赖关系
此时我们考虑在各业务 调用 基础服务之间，增加中间层。该中间层实现对错综复杂的服务进行治理。
1.5 SOA 架构（在分布式架构上，增加服务治理层）
SOA：Service-Oriented Architecture，表示面向服务的架构（并不再是分布式之前的面向系统），SOA 的关键就是增加了对服务的调度和治理层，提高机器的利用率。落地实现有 ESB 总线/ Dubbo 框架
分布式架构的问题缺陷：
-
服务越来越多，需要管理每个服务的地址和状态
-
调用关系错综复杂，难以理清依赖关系
SOA 架构服务治理做了什么？
-
服务注册中心，实现服务自动注册和发现，无需人为记录服务地址。动态地监控服务状态
-
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
SOA 架构的问题缺陷（服务关系复杂）：
服务拆分的粒度不够，所以存在服务之间的依赖。比如上面架构图的订单服务中的订单查询需要用到用户服务的用户查询。
1.6 微服务架构（嫌SOA服务拆分的粒度不够，对基础服务进行二次拆分）
微服务进行二次拆分以后每一个服务都对应唯一的业务能力，做到单一职责。每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能需求。开发简单、开发效率提供，一个服务可能就是专一的只干一件事，微服务能够被小团推单独开发，这个小团队是2到5人的开发人员组成。
微服务架构缺点：
- 微服务过多，服务治理成本高，不利于系统维护
- 分布式系统开发的技术成本高（容错、分布式事务等）
SOA 架构和微服务架构的区别：
- SOA 架构服务的耦合度比微服务架构的耦合度高
- SOA 架构的服务是统一管理的。微服务架构的服务是自治的
- SOA 的服务调用往往是RPC远程调用技术。微服务架构的服务调用技术往往是HTTP的web请求
总结：通常中小型系统使用单机架构，随着用户量的增大，可以将系统改成垂直应用架构。随着用户的请求和并发量的增多、业务不断的扩展，就可以采用分布式的架构。但是分布式因为服务的增多有很多的弊端，在分布式的基础上衍化除了 SOA。有了 SOA 之后，在 SOA 的基础之上有搞出了微服务架构。在微服务架构中，如果需要一个功能，我们只需要对这个功能添加一个新的服务，就可以启动使用了。
单机架构（All-in-One）-> 集群架构（复制单机架构）-> 垂直应用架构（按照业务垂直拆分系统，业务间互不通信）->分布式架构（按照基础服务拆分业务，一个服务可以给多个业务调用）->SOA 面向服务架构（提供对服务的治理、统一调度，服务之间存在耦合等）-> 微服务（细粒度的拆分服务，做到服务的单一职责，服务的耦合极低）
2、分布式系统核心知识
2.1 分布式中的远程调用（RESTful 和 RPC）
在微服务架构中，通常存在多个服务之间的远程调用的需求。一次远程调用通常包含两个部分：序列化和通信协议。
（序列化：将参数、方法、接口等信息序列化为字节。通信协议：对字节进行两个进程之间的传输）
目前主流的远程调用技术：
RESTfull 架构：
- 每一个URI代表一种资源；
- 客户端和服务器之间，传递这种资源的某种表现层；
- 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
RPC 就是要像调用本地函数一样去调用远程函数
RPC 调用工作原理：客户端调用，序列化调用的参数、方法、接口等信息，建立客户端和远程服务端的 TCP 连接，发送序列化后的字节信息。远程服务端接收到信息以后，进行反序列化，调用本地服务来处理请求，将结果序列化后并返回给客户端，然后客户端再反序列化该返回结果。
RESTful 和 RPC 调用对比：
2.2 分布式中的 CAP 原理
CAP 原理是用来衡量分布式系统架构是否符合要求的重要方式。分布式系统的最大难点，就是各个节点的状态如何同步，CAP 定理是这方面的基本定理，也是理解分布式系统的起点。
CAP原理详解
C（Consistency）强一致性： 多节点的数据一致
A（Availability）可用性： 保持服务一直可用（使用多节点）
P（Partition tolerance）分区容错性： 是否可以将数据存到多个地方
为什么 CAP 只能选其二？
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。
总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。
扫一扫
3760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
