开发者学堂课程【建立 Serverless 思维：构架的演进】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/644/detail/10715
构架的演进
内容介绍
一、应用架构的演进
二、云原生
一、应用架构的演进
1、单体架构：
(1)主要应用于十多年前
(2)部署形式：一台服务器加一个数据库；
(3)缺点：一是当这个服务器出现故障时会导致整个服务无法使用，这是一个可溶性风险，二是当业务增长以后，服务流量变大，一台服务器无法支撑整个服务
(4)解决方法：一是退距伸缩，代价比较高昂，而且会有瓶颈，二是水平伸缩。由于水平伸缩会更好，所以架构会演进成单体架构上的水平伸缩的形式。
2、单体架构（水平伸缩）：
(1) 部署形式：通常会在流量入口添加一个负载均衡，在均衡下加入更多的服务器；
(2)优点：可以解决以上两个问题，一是当一台服务器出现故障时，由于有更多的服务器，不会导致整个服务的不可用，二是当流量上升时，原本的一台服务器不足以支撑的问题，由于有了更多的服务器也就得以解决，因此这一种基于单体架构上的水平伸缩会给整个架构提供一个更好的可溶性保障；
(3)缺点：单体架构上去做一些研究时，随着研发会出现研究人员越来越多，研究人员之间的冲突会加剧，因为单体架构下面的代码是没有明确的物理学边界的，所以通常引入微服务架构。
3、微服务架构：
(1)优点：能够帮忙解决的问题，一般来说团队变大以后，研究人员为了更好的进行研发并做一些开发、测试、部署、运维的一些工作，就会把一个架构拆分成以下样式。
(2)缺点：微服务架构下的分布式问题变为默认问题，由此为了服务与服务之间进行通讯，分布式会引入一些新的如GRPC、DUBBO等一些其他协议进行通讯，还会引入分布式缓存如Redis、分布式追踪服务等，这些都是分布式的一些转型。
除了分布式环境带来的挑战之外，微服务架构给运维环境也带来了新的挑战。研发人员原本只需要运维一个应用，现在可能需要运维十个甚至更多的应用，这意味着安全patch升级、容量评估、故障诊断等事务的工作量成倍增加。这时，应用分发标准、生命周期标准、观测标准、自动化弹性等能力的重要性也更加凸显。
二、云原生
1、基于云产品架构：
判断一个架构是否是云原生，就看这个架构是否是长在云上的，这是对“云原生”的简单理解。
这个长在云上不是简单地说用云的 laaS 服务，比如 ECS、OSS 这些基本的计算存储；而是应该理解成有没有使用云上的分布式服务，比如 Redis、Kafka 等，这些才是直接影响到业务架构的服务。在微服务架构下，分布式服务是必要的，原来大家都是自己研究开发这样的服务，或者基于开源版本自己运维这样的服务。而到了云原生时代，这些业务可以直接使用云服务。
另外两个不得不提的技术就是 Docker和Kubenetes ,其中，前者标准化了应用分发的标准，不论是 Spring Boot 写的应用，还是 NodeJS 写的应用，都以镜像的方式分发；而后者在前者的技术上又定义了应用生命周期的标准，一个应用从启动到上线，再到健康检查，再到下线，都有了统一的标准。
2、应用生命周期托管
有了应用分发的标准和生命周期的标准，云就能提供标准化的应用托管服务，包括应用的版本管理、发布、上线的观测、自愈等。
例如对于无状态的应用来说，一个底层物理点的故障根本不会影响到研发，因为应用托管服务是基于标准化，应用生命周期可以自动完成腾挪工作，在故障物理节点上将应用的容器下线，在新的物理节点上将启动同等数量的应用容器。可以看出，云原生进一步释放了价值红利。
在此基础上，由于托管服务能够感知到应用运行的周期的数据，例如业务流量的并发、cpuload、内存占用等，业务就可以配置基于这些指标的伸缩规则，再由平台执行这些规则，根据业务流量的实际情况增加或减少容器数量，这就是最基本的 auto scaling 自动伸缩。这些能够帮助用户避免在业务低峰期限制资源，节省成本，提高运维效率。
