开发者学堂课程【架构的演进：构架的演进】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/841/detail/14008
构架的演进
内容简介：
1. 应用架构的演进方式
2. 云原生
一、 应用架构的演进方式
为了能够更好的学习 serverless，我们首先来回顾一下应用架构的演进方式。
10 多年前，主流的应用架构都是单体架构，部署形式就是一台服务器加一台数据库，在这种情况下，运营人员小心翼翼的维护这台服务器。但单体架构存在一些问题：
l 可用性风险：当这台服务器出现问题时，整个服务都将无法使用；
l 业务增长后，服务量增大，单台服务器无法支撑。
这时通常会有两种做法：垂直伸缩和水平伸缩，根据过往经验，垂直伸缩代价相对比较高昂，且存在瓶颈，相比之下水平伸缩更好。架构此时会演进成下图所示的方式：
通常会在流量入口添加一个负载均衡，在负载均衡下挂更多的服务器，这时，当一台服务器出现问题时，还有其他服务器来完成，不会导致整个服务的不可用，服务量增大，加入更多的服务器来解决这个问题。上文的两个问题也就解决了。
因此，这样一种基于单体架构的水平伸缩能力会为整个架构提供更好的可用性保障。
其实，这种架构还有一些问题，在一个单体架构上做研发时，由于单体结构下代码没有明确的物理边界，随着研发人员数量的增加，人员之间的冲突会越来越严重，为了解决这个问题，通常会引入微服务架构。微服务架构在逻辑上可以帮助解决此问题。一般来说团队扩大后，为了可以更好地进行研发，开发、测试、部署、运维的工作，就会把一个大的单体应用拆分为一个与下图类似的微服务架构。在这种架构下会引入一些新的挑战。其中最明显的就是分布式问题，这也是微服务架构的默认问题。分布式会引入一些新的技术，为了在服务与服务之间进行通讯，会引入GRPC、Double 等协议进行通讯，还可以通过异步方式如 Kafka 来收发信息，还会引入像分布式缓存 Redis、分布式追踪服务 traceid。
其实分布式环境下的微服务架构的拆分，一般会基于一些比较好的方法论，例如领域驱动设计中的限定上下文（qualify context），这是比较推荐大家理解的内容，因为拆分好的微服务会大幅度的提升研发效率，但拆分如果出现问题，研发效率反而会下降。
从单体架构引进的微服务架构从物理角度来看，分布式成为了默认选项，上文提到的一些相关技术就需要我们去做。
二、 云原生
最简单的理解，一个架构是否是云原生，就看这个架构是否“长在云上”。这里的长在云上不能简单的以IaaS服务来理解，例如简单的 ECS 或 OSS 第三存储，应该理解为这个架构是否基于云尝试的分布式服务来架构的，因为只有这些分布式服务才会影响到业务的架构。
在云时代之前，大家会自己来搭建这样的服务，云时代到来后，大家都会默认的选择一些云服务来实现，因为这样更快，且能获得更好的保障。
另外两个不得不提的技术就是 docker 和 Hadoop，前者标准化了一个应用分发的标准，后者在前者的基础上，定义了应用生命周期的标准，一个应用从启动、上线、到健康检查都有了统一的标准。有了应用的分发标准和应用的生命周期标准后，一个云服务平台就可以很容易的做成一个生命周期托管的服务，包括应用的版本管理、发布上线、观测。对于无状态应用来说，一个底层物理结点的故障，通常不会对应用研发造成感知，因为应用托管服务可以识别出有故障的物理节点，并将应用容器从此节点下掉，在新节点扩出一个容器，整个过程对应用无感，这就是云原生和云原生托管服务为应用带来的好处。
还有一些可以证明云原生价值的例子。业务一般有高峰期和低峰期，由于应用托管到了一个云原生的平台上，那么这个应用的一些指标，如运行时期的CPU、内存、流量变化、并发度等数据，都可以从平台得到，用户只需要根据这些数据配置简单的规则，平台就可以在低峰期下线一些实例，高峰期扩充实例，从而降低业务成本，在高峰时及时响应流量的变化保证服务的可用性。
在架构演进的过程中，我们可以发现研发人员逐渐的把关注点从机器转移到业务，而平台则会更多的负责机器管理问题，这就是一个非常朴素的关于serverless的理解。
