开发者学堂课程【Serverless 与微服务：Serverless 下的微服务实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/844/detail/14014
Serverless 下的微服务实践
内容简介:
一、 微服务架构介绍
二、 云原生时代下微服务架构的发展
三、 微服务 +Serverless 最佳实践
一、微服务架构介绍:
（一）微服务架构诞生背景
1. 互联网早期 (Web 1.0)
l 门户时代
l 单体应用
l 研发团队小
2. 新世纪互联网
l 社交&电商
l 流量&复杂度大增
l 研发团队扩大
l SOA/ 微服务架构
3. 移动互联网
l 生活全面互联网化
l 流量&复杂度爆发
l 研发团队大
l 效率要求高
l 微服务架构
4. 全面数字化
l 社会全面互联网化
l 流量&复杂度挑战
l 研发团队更大
l 效率要求更高
l 版本极速迭代
l 微服务架构
（二）业务架构改造
1. 单体时期架构
2.微服务时期架构
3. 单体架构与微服务架构对比
l 单体架构
l 共享代码库，容易冲突
l 边界不清，模块耦合
l 团队效率低
l 微服务架构
l 拆分:解耦研发态
l 拆分:解耦部署态
l 拆分:释放团队效率
二、云原生时代下微服务架构的发展
（一） 微服务的云原生化
云原生是一个很大的概念,而如果我们以微服务为起点，来看云原生给微服务代练的变化与演进，可以帮助我们更好的理解什么是云原生。
1. 生命周期管理
l 曾经的单体应用与资源之间的关系十分简单，单体应用的协同也都是一些内部协同，不存在外部动态的依赖。
l 架构转换到微服务之后，由于外部依赖与节点数量的爆炸。整个体系会变成网状，管理起来十分复杂。
l 如今，比较公认的一点就是，云原生的根基就是在于容器与容器的管理编排 (K8S).
l 而容器与 K8S 的技术就能帮助我们解决微服务体系存在的异常复杂的运维问题。
Pod :一组容器的集合，与微服务实体的生命周期的耦合。Sidecar :为主容器提供辅助功能。
l 容器平台或者云平台的应用引擎也能帮助我们便利的进行微服务应用的更新、发布、扩缩容等操作。
2. 流量治理
l 微服务将曾经单体时代的(通常是在编译时确定的)静态通信关系，通过拆分编程了动态运行时。
l 因此，服务之间的通信与协同需要单独管理，而这样一个作为每个服务的通用功能，通过微服务框架帮我们进行了抽象与实现。
l 但是不同的微服务框架的实现方式是不一样的。默认情况下是,不同框架之间的服务无法直接调用。
l 而类似上述异构情况，正是云原生想要支持与解决的。并且，容器、Pod 这些抽象就很好的提供了一个解决思路。
l Service Mesh 服务网格就是为了解决流量治理在多语言，多环境下的问题。
l 数据层面，Sidecar 负责流量劫持转发以及管理,该功能典型的 Sidecar 实现就是Envoy。
l 管控层面,也需要一个组件来实现原微服务体系中的策略规则的管理，经典实现有Istio。
3. 编程模型
l 请求驱动，是基于请求的动态弹性伸缩。
l 请求驱动模型:
l 请求标准化
l 请求路由
l 处理管理
l 将请求标准化、请求路由、处理管理组合起来，其实就是 Serverless 的概念了。
三、微服务+Serverless 最佳实践
(一) Serverless 的发展进程
(二) Serverless 市场概况
(三) 微服务架构痛点
l 容器与 K8S 自身复杂性
l 容器镜像部署方式差异
l K8S组件运维的复杂
l 学习成本
（四）理想状态-Serverless 应用引擎
l 专注业务逻辑
l 不改变原有开发方式
l 无需关心与运维底层资源
l 具备弹性能力可以降低闲时成本
l 优秀的工具链
（五）微服务体系在不同时代的实践
