总目录展示
该笔记共八个节点（由浅入深），分为三大模块。
高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。
一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。
高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。
篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）
由于内容太多，这里只截取部分的内容。
2.1.1 运行态
先说运行态，业务流量从我们网关进来，调用到 FC API Server，转发到 C++/Go Faas Runtime，runtime 来完成用户函数里的功能。runtime 的架构本文下一章节会具体介绍。
和 runtime container 一起部署的有监控、日志、Dapr 各种 side car，side car 来完成各种日志采集上报功能，dapr side car 来完成调用集团中间件的功能。
另外目前 dapr 还在试点的阶段，调用中间件主要是通过 Broker 和各个中间件 proxy 来完成，中间件调用的有HSF、Tair、metaq、diamond 等中间件 proxy。
最后 Autoscaling 模块来管理函数实例的扩缩容，达到函数自动伸缩的目的。这里的调度就有各种策略了，有根据请求并发量的调度、函数实例的 CPU 使用率的调度。也能提前设置预留实例数，避免缩容到 0 之后的冷启动问题。
底层调用的是集团 ASI 的能力，ASI 可以简单理解为集团的 K8S+ sigma（集团的调度系统），最终的部署是 FC 调用 ASI 来完成函数实例部署，弹性伸缩的，部署的最小单位是上图中的 pod，一个 pod 里包含 runtime container 和 sidecar set container。
2.1.2 研发态
再来看研发态，运行态决定函数是如何运行的，研发态关注函数的开发体验，如何方便地让开发者开发、调试、部署、测试一个函数。
C++ Faas 有个跨平台的难点问题，C++ Faas runtime 里有一些依赖库，这些依赖库没有 Java 依赖库管理那么方便。这样依赖库的安装比较麻烦，Faas 脚手架就是为了解决这个问题，调用脚手架，一键生成 C++ Faas 示例工程，安装好各种依赖包。为了本地能方便地 debug，开发了一个 C++ Faas Runtime Boot 模块，函数 runtime 启动入口在 boot 模块里，boot 模块里集成 runtime 和用户 Faas 函数，可以对 runtime 来做 debug 单步调试。
我们和集团 Aone 团队合作，函数的发布集成到 Aone 环境上了，可以很方便地在 Aone 上来发布 Go 或者 C++ Faas，Aone 上也集成了一键生成 example 代码库的功能。
C++ 和 Go Faas 的编译都依赖相应的编译环境，Aone 提供了自定义编译镜像的功能，我们上传了编译镜像到集团的公共镜像库，函数编译时，在函数的代码库里指定相应的编译镜像，编译镜像里安装了 Faas 的依赖库、SDK等。
2.1.3 运维态
最后来看函数的运维监控，runtime 内部集成了鹰眼、sunfire 采集日志的功能，runtime 里面会写这些日志，通过 sidecar 里的 agent 采集到鹰眼、或者 sunfire 监控平台上去（FC 是通过 SLS 来采集的）之后，就能使用集团现有的监控平台来做 Faas 的监控了，也能接入集团的 GOC 报警平台。
上面讲的是和 Aone、FC/CSE、ASI 集成的一个整体架构，Runtime 是这个整体架构的一部分，下面具体讲讲 Runtime 的架构是怎样的，Runtime 是如何设计和实现的。
最上面部分的用户 Faas 代码只需要依赖 Faas SDK 就可以了，用户只需要实现 Faas SDK 里的 Function 接口就能写自己的 Faas 了。然后如果需要调用外部系统，可以通过 SDK 里的 Http Client 来调用，如果要调用外部中间件，通过 SDK 里的 Diamond/Tair/HSF/metaq Client 来调用中间件就可以。SDK 里的这些接口屏蔽了底层实现的复杂性，用户不需要关心这些调用最后是如何实现，不需要关心 runtime 的具体实现。
SDK 层就是上面提到的 Function 定义和各种中间件调用的接口定义。SDK 代码是开发给 Faas 用户的。SDK 做的比较轻薄，主要是接口定义，不包含具体的实现。调用中间件的具体实现在 Runtime 里有两种实现方式。
往下是 Runtime 的一个整体架构。Starter 是 runtime 的启动模块，启动之后，runtime 自身是一个 Server，启动的时候根据 Function Config 模块的配置来启动 runtime，runtime 启动之后开启请求和管理监听模式。
再往下是 Service 层，实现 SDK 里定义的中间件调用的接口，包含 RSocket 和 dapr 两种实现方式，RSocket 是通过 RSocket broker 的模式来调用中间件的，runtime 里集成了 dapr（distributed application runtime），调用中间件也可以通过 dapr 来调用，在前期 dapr 试点阶段，如果通过 dapr 调用中间件失败了，会降级到 rsocket 的方式来调用中间件。
再往下就是 rsocket 的协议层，封装了调用 rsocket 的各种 metadata 协议。dapr 调用是通过 grpc 方式来调用的。
最下面一层就是集成了 rsocket 和 dapr 了。
rsocket 调用还涉及到 broker 选择的问题，upstream 模块来管理 broker cluster、broker 的注册反注册、keepalive 检查等等，LoadBalance 模块来实现 broker 的负载均衡选择以及事件管理、连接管理、重连等等。
最后 runtime 里的 metrics 模块负责鹰眼 trace 的接入，通过 filter 模式来拦截 Faas 链路的耗时，并输出鹰眼日志。打印 sunfire 日志，供 sidecar 去采集。下图是一个实际业务的 sunfire 监控界面：
2.2.1 Dapr
dapr 架构如下图所示，具体可以参考官方文档。
runtime 里以前调用中间件是通过 rsocket 方式来调用的，这里 rsocket broker 会有一个中心化问题，为了解决 outgoing 流量去中心化问题，和集团中间件团队合作引入了 dapr 架构。只是 runtime 层面集成了 dapr，对于用户 Faas 来说无感知，不需要关心具体调用中间件是通过 rsocket 调用的还是通过 dapr 调用的。后面 runtime 调用中间件切换到 dapr 之后，用户 Faas 也是不需要做任何修改的。
==============================================================================================
如前文所述，接入统一在 Aone 上接入。提供了 C++ Faas/Go Faas 的接入文档。提供了函数的 example 代码库，代码库有各种场景的示例，包括调用集团各种中间件的代码示例。C++ Faas/Go Faas 的接入对整个集团开发，目前已经有一些高德以外的 BU，在自己的业务中落地了 C++ /Go Faas。Node.js Faas 使用淘宝提供的 runtime 和模板来接入，Java Faas 使用阿里云 FC 提供的 runtime 和模板来接入就可以了。
针对落地新技术大家可能担心的稳定性问题，我们的应对法宝是阿里集团的稳定性三板斧：可监控、可灰度、可回滚。建立 Faas 链路保障群，拉通上下游各相关业务方、基础平台一起，按照集团的 1-5-10 要求，共同努力做到 1 分钟之内响应线上报警、快速排查；5 分钟之内处理；10 分钟之内恢复。
为了规范接入过程，避免犯错误引发线上故障，我们制定了 Faas 接入规范和 checkList，来帮助业务方快速使用 Faas。
可监控、可灰度、可回滚是硬性要求，除此之外，业务方如果能做到可降级就更好了。我们的 C++ 客户端上云业务，在开始试点阶段，就做好了可降级的准备，如果调用 Faas 端失败，本次调用将会自动降级到本地调用。基本对客户端功能无损，只是会增加一些响应延迟，另外客户端上该功能的版本，可能会比服务端稍微老一点，但是功能是向前兼容的，基本不影响客户端使用。
====================================================================================
-
Go/C++ Faas Runtime 开发完成，对接 FC-Ginkgo/CSE、Aone 完成，已发布稳定的 1.0 版本。
-
做了大量的稳定性建设、优雅下线、性能优化、C 编译器优化，使用了阿里云基础软件部编译器优化团队提供的编译方式来优化 C++ Faas 的编译，性能提升明显。
-
C++/Go Faas 接入鹰眼、sunfire 监控完成，函数具备了可观测性。
-
池化功能完成，具备秒级弹性的能力。池化 runtime 镜像接入 CSE，扩一个新实例的时间由原来的分钟级变为秒级。
C++ Faas 和 Go Faas 以及 Node.js Faas 在高德内部已经有大量的应用落地。举几个例子：
上图中的前两个图是 C++ Faas 开发的业务：长途天气、沿途搜。后两个截图是 Go-Faas 开发的业务：导航 tips、足迹地图。
高德是阿里集团内 Serverless 应用落地规模最大 的BU，已落地的 Serverless 应用，日常峰值超过十万 qps 量级。
高德落地了集团内规模最大的 Serverless 应用之后，都有哪些收益呢？
首先第一个最重要的收益是：开发提效。我们基于 Serverless 实现的端云一体组件，助力了客户端上云，解除了需要实时的客户端发版依赖问题，提升了客户端的开发迭代效率。基于 Serverless 开发的 BFF 层，提升了 BFF 类场景的开发迭代效率。
第二个收益是：运维提效。利用 Serverless 的自动弹性扩缩容技术，高德应对各种出行高峰就更从容了。例如每年的十一出行节、五一、清明、春节的出行高峰，不再需要运维或者业务开发同学在节前提前扩容，节后再缩容了。高德业务高峰的特点还不同于电商的秒杀场景。出行高峰的流量不是在 1 秒内突然涨起来的，我们目前利用池化技术实现的秒级弹性的能力，完全能满足高德的这个业务场景需求。
第三个收益是：降低成本。高德的业务特点，白天流量大、夜间流量低，高峰值和低谷值差异较大，时间段区分明显。利用 Serverless 在夜间流量低峰时自动缩容技术，极大地降低了服务器资源的成本。
==================================================================================
-
FC 弹内函数计算使用优化，和 FC 团队一起持续优化弹内函数计算的性能、稳定性、使用体验。用集团内丰富的大流量业务场景，来不断打磨好 C++/Go Faas Runtime，并最终输出到公有云，普惠数字化转型浪潮中的更多企业。
-
Dapr 落地，解决 outcoming 流量去中心化问题，逐步上线一些 C++/Go Faas，使用 Dapr 的方式调用集团中间件。
-
Faas 混沌工程，故障演练，逃生能力建设。Faas 在新财年也会参与我们 BU 的故障演练，逐一解决演练过程中发现的问题。
-
接入边缘计算。端云一体的场景下，Faas + 边缘计算，能提供更低的延时，更好的用户体验。
最后
做任何事情都要用心，要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局，思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局，未来你的路会走的更远。
更多的技术点思维导图我已经做了一个整理，涵盖了当下互联网最流行99%的技术点，在这里我将这份导图分享出来，以及为金九银十准备的一整套面试体系，上到集合，下到分布式微服务
31110)]
[外链图片转存中…(img-GlwhXwcN-1714996631111)]
619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
