讲架构演进之路与前沿技术海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

本会讲解分布式系统架构以及面试中做项目介绍的技巧，重点有如下三部分。

1.介绍系统架构的演进：包括微服务架构、云原生以及业界趋势ServiceMesh。

2.讲解微服务的基础知识点：Docker和K8s。

3.面试技巧，教你如何更有效地做项目介绍。

系统架构演进

首先以演进的方式来了解不同的系统架构。

单体架构

最简单的系统架构是单体服务，如下图所示。

一个项目中的多个服务，混合部署在一个进程内，服务之间的交互都是通过进程内调用完成的，正如图

中Service之间的红色箭头所示。这样做的好处是可以快速开发、部署服务，服务之间调用的性能也最

好。

当然，这种架构缺点也非常多，比如：

随着业务的增长，项目越来越臃肿；

服务之间因为JAR包导致频繁的依赖；

服务资源变更，因为一个服务可能被多个不同的业务，升级资源需要多个业务方同时升

级；

因为不同业务方都可以直连服务的数据资源，这个架构也存在明显的数据安全风险；

修改代码后回归、架构难以调整等等。

以上所有问题都是因为服务耦合在一起导致的。在服务规模不大的情况下，比较适合采用单体架构，方

便快速迭代。但是当服务规模变大时，单体架构就不是一个好的选择。

微服务架构

当服务的规模变大时，为了解决服务耦合的问题，出现了SOA就是面向服务架构，它的是为了解

决企业应用问题，随着不断演进，发展到目前业界普遍采用的微服务架构，微服务架构如下所示。

微服务架构的思想就是让服务尽可能做到高内聚、低耦合，不同的服务单独开发、单独测试、单独部

署。服务之间通过RPC或者HTTP进行交互，如图中的蓝色加粗箭头所示。

微服务架构解决了单体架构的耦合问题，但同时也带来了新的问题。因为署在不同的进程或服务

器中，要使用服务前需要先找到服务，即所谓的服务发现。

一般微服务使用两种发现方式，一种是前面课程介绍过的RPC方式，通过进行服务的和

订阅，来完成服务发现，比如图中间灰色的Registry模块。这种方式由服务的调用端获得到全部可用服

务节点，由Client侧进行负载均衡，调用服务。另外一种是通过HTTP协议调用服务端提供的RESTful

接口，这种方式不需要Client侧做服务发现，而是在Server端通过Nignx这样的反向来提供

Server侧的负载均衡。

不论哪种方式，服务的交互都从进程内通信变成了通信，所以性能必然会受到一些影响。此外由于

很多不确定性的因素，例如网络拥塞、Server端服务器宕机、挖掘机铲断机房光纤等等，需要许多额外

的功能和措施才能保证微服务流畅稳定的工作。前面在SpringCloud内容中提到的Hystrix熔断器、

Ribbon客户端负载均衡器、Eureka等等都是用来解决这些问题的微服务组件。

CAP原则与BASE理论

在微服务架构中，有必要了解一下分布式系统中的CAP原则与BASE理论。如下图所示，CAP原则指

的是在一个分布式系统中，Consistency一致性、Availability可用性、Partitiontolerance分区容错

性，这三个特性最多只能同时满足两个，三者不可兼得。

其中一致性指所有节点在同一时间的数据完全一致；可用性指任何时候对分布式系统总是可以成功读和

写；分区容错性是指当某些节点或网络分区故障的时候，仍然能够提供满足一致性和可用性的服务。

既然无法同时满足三个特征，那就会有三种取舍。

第一个选择是CA，就是放弃分区容错，这也就等同于放弃了分布式系统，所以CA只存在于单机系统。

第二个选择是CP，也就是选择强一致和分区容错，允许情况下出现短时的服务不可用。采用CP原

则实现的分布式系统比如ZooKeeper。ZooKeeper是一个分布式协调系统，强一致性是ZK的主要目

标，允许出现短时的系统不可用。也正是因为这个，ZK其实并不适合用来做微服务的