diff --git a/assets/js/app.js b/assets/js/app.js
index 2fc09a825..6589f0599 100644
--- a/assets/js/app.js
+++ b/assets/js/app.js
@@ -33,6 +33,7 @@ const main = () => {
   // image zoom
   $$('.typo img').forEach(imgElem => {
     zoom(imgElem)
+
   })
 }
 
diff --git a/content/zh/activities/sofa-channel-34/index.md b/content/zh/activities/sofa-channel-34/index.md
new file mode 100644
index 000000000..a1c32c63d
--- /dev/null
+++ b/content/zh/activities/sofa-channel-34/index.md
@@ -0,0 +1,63 @@
+---
+title: "SOFAChannel#34《Dragonfly & Nydus 在 AI 场景下的加速实践》——Dragonfly 社区"
+authorlink: "https://github.com/sofastack"
+description: "Dragonfly & Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。"
+categories: "SOFAStack"
+tags: ["SOFAStack"]
+date: 2023-08-02T15:00:00+08:00
+cover: "https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*ISmkSYboiIkAAAAAAAAAAAAADrGAAQ/original"
+---
+
+## Dragonfly 项目简介
+
+Dragonfly 是一款基于 P2P 的镜像加速和文件分发系统。它旨在提高大规模文件传输的效率和速率，最大限度地利用网络带宽。在 AI 数据分发、文件分发、日志分发和镜像分发等领域被大规模使用。在解决大规模文件分发场景下有着无可比拟的优势。
+
+自 2017 年开源以来，Dragonfly 被许多大规模互联网公司选用并投入生产使用，并在 2018 年 10 月正式进入 CNCF，成为中国第三个进入 CNCF Sandbox 级别的项目。2020 年 4 月，CNCF 技术监督委员会（TOC）投票决定接受 Dragonfly 作为 Incubating 级别的托管项目。
+
+SOFAChannel#34 就邀请到了**蚂蚁集团技术专家、Dragonfly 项目 Maintainer 戚文博**跟大家分享 **Dragonfly & Nydus 在 AI 场景下的实践**。
+
+![img](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*ZLHNSaDyevcAAAAAAAAAAAAADrGAAQ/original)
+
+## 直播介绍
+
+**《Dragonfly & Nydus 在 AI 场景下的加速实践》**
+
+2023 年 8 月 9 日（周三）
+
+19：00 - 20：00
+
+**「嘉宾简介」**
+
+戚文博（花名：百蓦）
+
+蚂蚁集团技术专家
+
+Dragonfly Maintainer
+
+**「议题简介」**
+
+在 AI 场景下，训练和推理两个过程中，数据的传输往往是关键瓶颈之一。Dragonfly & Nydus 作为 CNCF Incubating 项目，其利用 P2P 技术和按需加载能力，能够大幅度提升数据传输的速度和效率，从而提高 AI 计算的整体效率和性能。这使得 AI 算法的训练和推理过程中数据传输更加高效和可靠，为 AI 技术的应用提供了强有力的支撑。
+
+**「听众收获」**
+
+1、了解并走进 Dragonfly 项目；
+
+2、镜像加速领域相关技术的分享；
+
+3、Dragonfly & Nydus 在 AI 场景下的实践。
+
+## 直播预约
+
+**钉钉搜索**：22880028764
+
+钉钉群同步直播，讲师在线答疑
+
+**B 站直播预约** 有机会获得 Dragonfly 精美贴纸～
+
+[https://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0](https://www.bilibili.com/opus/825142485488500792?spm_id_from=444.41.0.0)
+
+## 了解更多技术干货
+
+使用钉钉搜索群号：**44858463**，即可加入，获取一手开源技术干货；或微信扫码关注“金融级分布式架构”微信公众号👇
+
+![img](https://gw.alipayobjects.com/mdn/rms_1c90e8/afts/img/A*_a06Q7zMKnwAAAAAAAAAAAAAARQnAQ)
diff --git a/content/zh/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.md b/content/zh/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.md
new file mode 100644
index 000000000..9da106c24
--- /dev/null
+++ b/content/zh/blog/ant-group-sofa-serverless-new-microservices-architecture-exploration-and-practice/index.md
@@ -0,0 +1,138 @@
+---
+title: "蚂蚁 SOFAServerless 微服务新架构的探索与实践"
+authorlink: "https://github.com/sofastack"
+description: "蚂蚁 SOFAServerless 微服务新架构的探索与实践"
+categories: "SOFAStack"
+tags: ["SOFAStack"]
+date: 2023-08-22T15:00:00+08:00
+cover: "https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*u3X0Ra7M3kUAAAAAAAAAAAAADrGAAQ/original"
+---
+
+## 作者简介
+
+**赵真灵（有济）**
+
+蚂蚁集团技术专家，Serverless 和微服务领域专家
+
+曾负责基于 K8s Deployment 的应用发布运维平台建设、K8s 集群的 Node/pod 多级弹性伸缩与产品建设。当前主要负责应用架构演进和 Serverless 相关工作。同时也是 SOFAArk 社区的开发和维护者以及 KNative 社区的贡献者。
+
+**本文** **3612** **字，预计阅读** **12** **分钟**
+
+## 传统微服务架构面临的问题和挑战？
+
+应用架构从单体应用发展到微服务，结合软件工程从瀑布模式到当前的 DevOps 模式的发展，解决了可扩展、分布式、分工协作等问题，为企业提供较好的敏捷性与执行效率，给企业带来了明显的价值。但该模式发展至今，虽然解决了一些问题，也有微服务自身的问题慢慢暴露出来，在当前已经得到持续关注：
+
+**1、业务开发者需要感知复杂的基础设施，启动慢（*分钟级*），研发效率低，运维负担重：**
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*ac6EQYrDVJ0AAAAAAAAAAAAADrGAAQ/original)
+
+对于基础设施的问题，在服务网格和应用运行时的工作已经取得了一定的成果，但是基础设施到业务开发之间还存在业务通用的部分，这里当前没有一个模式来给予支持。
+
+当前已经有一些开源项目在尝试解决基础设施的问题，例如服务网格、应用运行时，如 Dapr/Layotto，也都在实际应用中得到了不错的效果。但当前服务网格和应用运行时更多的是将中间件以下下沉到 sidecar，而一个应用一般还包括通用的业务逻辑部分，要让更广泛的业务也能享受到无基础设施的体感，也需要让业务以下（*可以把业务层以下的看作基础设施*）都能屏蔽。另外当前对于中小企业来说，使用服务网格和应用运行时的成本还是比较高的。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*98u5TKM73EAAAAAAAAAAAAAADrGAAQ/original)
+
+**2、拆分微服务的资源与维护成本高：**
+
+拆分后每个子应用都包含公共部分（*框架、中间件等*），除了同样存在上述第一个问题之外，还需要独占机器资源成本高，如果部分业务萎缩，会面临长尾应用问题，需要承担长期维护的成本。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*98u5TKM73EAAAAAAAAAAAAAADrGAAQ/original)
+
+**3、拆分微服务的敏捷度与业务、组织发展的敏捷度不一致，导致如何合理地拆分微服务始终是个老大难的问题：**
+
+*   拆得多增加了资源和管理成本；
+*   拆得不够造成协作效率问题。有些是应该拆但没拆，有些是因为业务领域已经较为细分不便再拆，特别在一些中小企业里，可能都没有微服务的配套设施。
+
+## **蚂蚁的解决思路和方案**
+
+为了解决这些问题，我们对应用同时做了横向和纵向的拆分。纵向拆分：把应用拆分成**基座**和**模块**两层，这两层分别对应两层的组织分工。基座小组与传统应用一样，负责机器维护、通用逻辑沉淀、模块架构治理，并为模块提供运行资源和环境。模块在业务层以下所有的基础设施、应用框架、中间件可以不再关注，聚焦在业务逻辑研发本身；并且采用 jar 包的研发模式，具备秒级的验证能力，让模块开发得到极致的提效。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*_mjHSYZhO90AAAAAAAAAAAAADrGAAQ/original)
+
+这可以理解为这套架构的核心模型，核心的能力有两个：**平台化 + 模块化**。模块化是 20 年前 OSGI 就已经提出的概念，从 OSGI 到 JPMS 一直未被抛弃，到最近 Spring Modulith、Service Weaver 等行业里又兴起一些开源框架，它一直在发展；平台化从 2017 年出现在技术雷达到 2023 年被 Gartner 列为十大战略趋势之一，到现在国内的平台工程，不断得到重视和发展。而我们实际上在行业还没有对这两个技术方向充分关注的情况下，就在尝试把他们结合起来，并在蚂蚁内部得到规模化验证和落地，给业务带来极致的降本增效效果。
+
+该模式的另一个特点是**可演进、可回滚**。这里的模块随着业务发展壮大，可以独立部署成微服务；如果微服务拆分过多，可以低成本改造成模块，合并部署在一起，解决资源成本和长期维护成本。实际上可以理解为我们是在单体应用架构和传统微服务架构中间，增加了一个可以演进过渡的架构。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*f_RAQJprMRUAAAAAAAAAAAAADrGAAQ/original)
+
+总结下来这套新微服务架构可以解决这四个问题：
+
+1、横向拆分出基座屏蔽业务以下的基础设施、框架、中间件和业务通用逻辑等部分，从而极大降低了业务开发者的认知负荷、提高了开发效率。
+
+2、一个应用可以低成本改造或拆分出多个模块，模块间可以并行独立迭代，从而解决了多人协作阻塞问题，每个模块不单独占用机器资源，没有拆分的机器成本问题。
+
+3、存量微服务如果拆分过多，可以低成本改造成模块应用，合并部署在一起，解决拆分过多带来的资源成本和维护成本痛点。
+
+4、模块可以灵活部署，解决微服务拆分与组织发展灵敏度不一致导致的协作低效与分工不合理问题。应用拆分出多个模块，可以部署在一起，也可以进一步演进成独立微服务，同样如果微服务拆分过多，也可以低成本改回模块合并部署到一起。
+
+这里卖个关子——*为什么这些技术在蚂蚁能规模化落地？存量的业务 owner 在业务迭代进度和升级新架构之间做权衡时，我们做了哪些工作？* 欢迎来到 9 月 3 号 QCon 大会现场获得更详细的信息。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*nad3TZDq3IgAAAAAAAAAAAAADrGAAQ/original)
+
+## **在采用新的微服务架构模式后的成果**
+
+举个当前蚂蚁实际业务采用新模式前后的对比数据：
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*b7cWRbPeI6QAAAAAAAAAAAAADrGAAQ/original)
+
+可以看到这些数据是十倍级以上的提升，当前蚂蚁所有 BU 都已经接入，将近 40W core 的在线业务，并为两种业务模式：中台模式和轻应用模式的业务都提供秒级研发运维的能力。一个基座上面最多有上百个模块，一个开发同学在研发验证阶段，一下午可以验证上百次，需求的交付效率最快可以到小时级别。
+
+## **在当下行情下，新技术落地的挑战与蚂蚁的思路**
+
+当前行情下，企业对新技术会更加谨慎，技术人也对新技术采取保守态度。新技术虽然很酷，但投入大落地场景有限。这其实是发展过程的转换，在高速发展的行情下，一方面是历史包袱少，另一方面是乐观态度占据主导，更加相信新技术能较快得到规模化落地，整个社会都对新技术充满热情。而在当下阶段，很多企业已经有一定的历史包袱，时间证明新技术规模化落地需要很长的周期，需要整个体系一起演进才可能达到最初的预想，可能也会带来越来越繁复的基础设施，所以当前行业对新技术更加偏保守也是非常合理的。
+
+所以蚂蚁在建设这套微服务新架构时，有一个非常关键的设计思路，那就是要**接地气**或者是**可演进**，也即是要让存量业务能低成本接入。这也是最初蚂蚁在落地该模式时踩过的最大的坑：一个普通应用转换成基座需要花费上月时间（*包括流量迁移*），模块研发与现有基础设施不匹配导致模块研发成本也很高，这个问题在当时也影响了该模式的生死存亡。后来蚂蚁在这块上投入了很大精力，最终让普通应用在小时内可以成为基座或模块，研发模式也与普通应用基本一致。
+
+经过这个过程，最终低成本、可演进也成为了该模式的一个核心优势。未来对外开源，我们会把接地气做得更加彻底，不对企业的基础设施程度有预设条件：
+
+*   无需容器化也可以接入；
+*   无需使用 K8s 平台也可接入；
+*   无需具备微服务配套设施可也接入；
+*   无需服务网格化也可接入。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*mROOSYaAGOkAAAAAAAAAAAAADrGAAQ/original)
+
+## **微服务新架构落地实战中遇到的更具体的困难和挑战**
+
+我们做的这套模式在行业内没有先例，相当于是在无人区里摸索，因此面临多方面的挑战：
+
+1、关于模块化技术的质疑：为什么现在模块化技术又开始被关注？为什么我们基于 SOFAArk 的模块化技术能推广？挑战主要集中在如何制定合理的隔离和共享通信策略，我们需要避免 OSGI 之类的复杂度问题，做到可以低成本使用。
+
+2、模块化技术采用了多 ClassLoader，对于 ClassLoader 的隔离、卸载不干净等问题，我们一步一个脚印，深入并体系化分析底层问题，制定各种问题的解法，需要用实际效果证明多 ClassLoader 的问题对业务的影响能否控制在可控可接受范围内。
+
+3、不同于传统应用发布运维调度是建立在机器维度上的，我们在机器维度之上做了三层运维调度。这里成熟的配套能力需要多团队协作共同推动建设：运维能力、机器分组、流量分组调拨、监控、日志、trace、风险防御等都有全新的建设，而这些在蚂蚁现有的技术体系里，与现有的基础设施不匹配，有很多的适配改造、多团队协作推动工作。
+
+4、存量业务在快速迭代的压力下为何会选择接入这套新的模式？做到低成本是影响用户是否愿意接入的关键。我们在低成本上做了大量工作：基座的改造、存量的应用改造成模块、存量的应用拆分成多个模块等。
+
+5、这套模式对业务应用的分层，需要业务方团队的配合调整，其中的用户心智培养和宣讲，需要有一个过程。
+
+## 总结蚂蚁落地该模式的经验和启示以及未来微服务领域的发展趋势和展望
+
+一个新的模式不是一蹴而就的，更不是一夜之间就提出的。新模式的出现一般是在前人探索的基础上，用新的思路方法，保持解决问题的初心坚持下去，最终慢慢成型的。
+
+*   当前在解决基础设施屏蔽上，从 Docker 到 Kubernetes 到 sidecar 到应用运行时等方向在发展，这里更多是从底层向上层的发展。而我们实际上可以从另一个方向，也就是自上而下地来考虑建设，我们直接从应用这层做了纵向的拆分，把业务以下的所有部分打包成基座这层，基座及以下的所有基础设施也就直接对业务开发者屏蔽了。所以相同问题，从不同角度出发可以有新的方法，得到新的效果。
+*   3 年前的时候还没有那么多对微服务反思的声音，也还没有应用运行时（*Dapr*）的概念，对模块化技术也更多的是不看好；我们做的事情在行业里没有前人的指引。但我们依旧紧盯业务痛点，也并没有因为困难而采取妥协的策略，比如一个基座上只允许一个模块、一个模块只能使用 SPI 模式。我们实际上走了一条最难的路线，更多的是靠一群人的坚持、业务的理解和认可、组织的包容，才最终在蚂蚁得到规模化的落地。
+
+当前应用的架构，有两个方向的发展：纵向不断地把业务以下的逻辑和依赖下沉，横向不断地往更细粒度的方向发展。未来 Serverless 会有多种形态，但也是在这两个方向上的发展，例如 BaaS + FaaS 模式。但是存量应用如何使用上这套模式，一直是这个行业里的问题，这个问题既是挑战，也是行业里的机会。我们需要一套能让应用平滑、逐步演进到未来 Serverless 形态的应用架构和平台能力。
+
+软件架构好比建造一座大厦，是一层一层的沉淀稳定、一层一层的建设。观察 Kubernetes 资源编排这层已经成熟，当前领域里更多是在做 mesh/微服务这层，当这一层未来也成熟稳定时，相信也会出现几个类似 Kubernetes 的产品，这是我们当前的机会，当然其中也充满了挑战。
+
+今年我们会把我们这套能力对外开源，欢迎有志之士参与共建。关注 **SOFAServerless**，共同解决微服务领域里的问题，让 Serverless 在未来能成为一种普适的技术。
+
+欢迎 9 月 3 号 来 QCon 大会现场一起探讨**微服务架构新模式**。
+
+## 了解更多
+
+**SOFAServerless Star 一下✨：**
+
+*<https://github.com/sofastack/sofa-serverless>*
+
+## 推荐阅读
+
+[超越边界：FaaS 的应用实践和未来展望](https://mp.weixin.qq.com/s/mo6vYR3qXQXMW3ZK5dAuVg)
+
+[如何看待 Dapr、Layotto 这种多运行时架构？](https://mp.weixin.qq.com/s/dmvx6rGSMkrurGWSVDHkMw)
+
+[SOFABoot 4.0 正式发布，多项新特性等你来体验！](https://mp.weixin.qq.com/s/u6wsnI2rvbGcO-V2N-MZTw)
+
+[MoE 系列（七）｜ Envoy Go 扩展之沙箱安全](https://mp.weixin.qq.com/s/FEC-0d37yT6iWusY0N4Yqg)
diff --git a/content/zh/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.md b/content/zh/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.md
new file mode 100644
index 000000000..1426f3666
--- /dev/null
+++ b/content/zh/blog/beyond-boundaries-faas-adoption-practices-and-future-prospects/index.md
@@ -0,0 +1,266 @@
+---
+title: "超越边界：FaaS 的应用实践和未来展望"
+authorlink: "https://github.com/sofastack"
+description: "超越边界：FaaS 的应用实践和未来展望"
+categories: "SOFAStack"
+tags: ["SOFAStack"]
+date: 2023-08-15T15:00:00+08:00
+cover: "https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*wpD9R7kZYyAAAAAAAAAAAAAADrGAAQ/original"
+---
+
+# 作者简介
+
+**邢奇（薯片）**
+
+蚂蚁集团技术专家，云原生和 Service Mesh 领域专家
+
+长期从事服务治理和服务发现等相关领域的研究和实践，在 RPC 框架（*Dubbo、Spring Cloud 和 SOFARPC 等*）方面有源码级的研究和贡献；在 Service Mesh、云原生、容器和 K8s 等方面有深入的研究和实践经验。
+
+参与了多个开源项目的贡献，包括 MOSN、SOFA、Dubbo 和 Nacos 等。目前担任蚂蚁云开发技术负责人，负责支付宝云开发产品的研发和实践。
+
+**本文 5689 字，预计阅读 16 分钟**
+
+# 概述 
+
+什么是 FaaS ？
+
+在 ChatGPT 里面输入 FaaS 关键字，得到的结果是：*FaaS 是一种云计算服务模型*。它允许开发者编写和部署函数，而不需要管理底层基础设施的运行，即 Function as a Service。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*gxRZT6D0NF4AAAAAAAAAAAAADrGAAQ/original)
+
+同时通过 ChatGPT 可以生成对应的函数代码——
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*FITpRpOw3NMAAAAAAAAAAAAADrGAAQ/original)
+
+# FaaS 的崛起
+
+FaaS 的理念和函数研发模式，为传统的应用模式解决了许多问题，有着超前的优势。
+
+## 传统应用模式的困境
+
+在研发态，不管是单体应用还是微服务应用，亦或是 Mesh 架构或者应用运行时，在研发态，开发者除了要关注业务逻辑本身之外，经常会被中间件所打扰，需要配合去做 SDK 升级改造，性能或者功能优化等。同时在使用云产品或者云服务的时候，需要被迫去感知多云的差异。
+
+在运维态，开发者面临着更重的运维压力。当一个应用上线，开发者需要对这个业务的未来发展进行一个复杂且不确定的容量评估，再去为这个容量去申请对应的资源，最后经过一个复杂的上线流程进行发布。在发布结束之后，开发者还得时刻关注线上流量的变化，去进行不断的扩容和缩容的调整。
+
+总而言之，整个中间件和基础设施对开发者的打扰是非常严重的：
+
+-   应用研发模式的代码耦合严重，复杂度高；
+-   运维流程繁琐，效率低；
+-   容量评估一般很难符合真实情况，线上的资源利用率一般都较低，存在着浪费。
+
+于是 FaaS 函数的研发模式应运而生。
+
+可以很直观地看到，在传统应用和微服务应用的改造和优化的基础之上，FaaS 希望做得更进一步，更面向未来。以函数为编程对象，用户无需关注应用、机器等数据和基础设施信息。
+
+通过这样的改变，大大提升研发效能，做到快速开发；并且提高运维效率，提供一站式免运维的 Serverless 平台；最后，函数会随着流量进行创建和销毁，最终降低成本和资源的消耗。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*fCwfTZVcEN8AAAAAAAAAAAAADrGAAQ/original)
+
+## FaaS 使用场景
+
+尽管 FaaS 具有许多优势，但并非所有场景都适合采用函数编程模式。下面介绍一些 FaaS 适用的普遍场景：
+
+**1、BFF 的场景。** 即一些胶水代码（*对接多个接口、进行数据的组装和适配等*）。胶水代码的逻辑相对简单，但同时需求变化快、生命周期短。对应的应用场景如运营/营销活动等。活动结束之后，就不再有流量进入，也没有必要再进行代码和机器的维护。
+
+**2、事件驱动的场景。** 例如音视频转码，用户上传文件触发任务，或者通过消息触发调度，或者业务上有明显的波峰和波峰的流量特征。
+
+**3、中台型业务。** 例如算法平台的算子。算子计算是非常独立的业务逻辑，但是参与的研发人数非常多，逻辑相对来说不可控，需要有更高的隔离能力。
+
+# FaaS 落地面临的技术问题
+
+FaaS 技术产品的落地，可能会面临以下问题和挑战：
+
+**性能问题：**
+
+1、在传统的微服务架构下，开发者会为 RPC 调用性能进行了大量的优化；在 FaaS 的场景，也需要保证函数调用的性能。
+
+2、弹性扩缩容的反应时效性。很多 FaaS 产品会采用弹性的模型去采集 CPU、QPS 并发等指标，再通过平台去计算指标，进而进行一些扩容和缩容的操作，时效性很低。
+
+3、函数启动的速度。函数启动的速度在 FaaS 场景中至关重要，函数容器的创建和启动不仅仅是发布态的事情，而是一个数据面流量的依赖。
+
+**安全问题：**
+
+1、想要充分地利用计算资源以降低成本，其必要的前提就是有效地利用和隔离资源。
+
+2、代码容器。用户的函数代码跑在容器里面，防止容器逃逸就是重中之重。
+
+3、相较传统的编程模型而言，FaaS 的编程模型到底是如何屏蔽中间件以及云服务的干扰的呢？
+
+# 蚂蚁 FaaS 技术架构 
+
+蚂蚁在 FaaS 实践之初设定了 3 个 FaaS 技术架构实践的基本原则。
+
+**原则 1：流量模型。** 蚂蚁的函数容器是随着流量进行创建和销毁的，而不是通过指标数据进行分析的弹性模型。
+
+**原则 2：函数冷启动。** 尽管有 Warm Pool 或者 cache 技术可作选择，但为了最大程度降低成本和利用资源，蚂蚁将目标定为 100ms 以内的极致的冷启动。
+
+**原则 3：安全隔离。** 用户的函数都跑在我们的容器里面，因此必须保证高水位的安全隔离特性。
+
+其实，蚂蚁在实践 FaaS 技术架构时，有一个总的原则就是 **one request per instance**—极致的情况下，是创建一个函数容器去处理一个请求，类似编程模型创建一个线程去处理一个请求。在这里，创建函数容器就相当于创建一个线程，具有相似的快速、消耗低的优点，同时还有线程所不具备的安全隔离特性。
+
+## 架构说明
+
+### 组件介绍和功能说明
+
+**函数网关**：负责对函数请求进行转发和控制，并为每一个请求发起一次容器调度任务。
+
+**容器调度引擎**：负责对容器进行调度，维护容器的整个生命周期，并且可以对函数容器进行并发度和复用等状态控制，同时也负责管理整个集群的函数 Pod 资源池。（*函数 Pod 资源池是函数容器运行的一个环境，一个集群内会有 N 多个 Pod 资源池。* ）
+
+**函数运行时**：函数运行时是 OCI 标准的实现，它负责快速地启动函数容器，并对容器的 runtime 进行有效的控制。
+
+**函数容器**：函数容器可以理解为是函数运行时+runtime+用户代码的一个运行态，用户的函数代码就跑在函数容器中。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*p0beQZf7qE8AAAAAAAAAAAAADrGAAQ/original)
+
+### 数据面流量和调度流程说明
+
+从上图可以看到，所有请求都会通过函数网关进入到函数集群，函数网关会发起一次调度任务：通过容器调度引擎 Scheduler 为这一请求快速分配一个 Pod 资源。然后网关就会把这个流量转发给这个 Pod 资源里面的节点网关，节点网关随即缓存对应的请求，并且等待函数容器启动。同时函数节点调度器会并发地创建函数容器并且为容器挂载函数代码。函数容器在启动完成之后，就会立刻作为一个客户端去节点网关上拉取请求，然后进行业务逻辑处理。
+
+从上述流程中可以看到，蚂蚁 FaaS 场景中的 Serverless 有了第二层含义——no server（*没有 server*）。函数容器永远是作为一个 client 去处理请求。这样的方式从设计上就避免了对基础设施环境的依赖，同时减少了需要去打开一些网络端口、处理网络连接的损耗，也不需要像微服务应用那样去做一些 checkhealth 和 readliness 探针等之后才能进行注册，然后再进行服务发现和调用。
+
+## 性能优化实践
+
+### 函数网关
+
+FaaS 函数网关采用 Go 语言进行编写，网络编程模型是通过一个 go routine 处理一个请求的同步编程，比较符合开发者的习惯。同时由于 Go 语言良好的垃圾回收机制和 GPM 调度模型，网关也有了不错的性能。但是随着业务的不断增长，整个网关在高并发下会出现毛刺现象，P99 长尾也比较严重。
+
+基于以上情况，**新版的 FaaS 函数采用 Go 语言的 Gateway 运行在 C++ 语言的 Envoy 运行时上**。我们知道，越靠近 Linux 原生语言的方式性能越好。同时 Envoy 采用高性能的同步非阻塞网络编程模型，性能更优。所有的函数请求通过 Envoy 的网络接口进入，并且进行网络处理，然后通过 cgo 调用 Go 语言网关实现的 API 接口，这样 Gateway 网关就能在七层去做一些 filter 和路由的逻辑。最后将请求转发给对应的节点网关。节点网关会进行请求的缓存，同时可以收敛网关连接数。同时函数容器在 running 之后会通过 UDS 和节点网关进行交互。
+
+通过上述优化，可以看到整个函数网关的吞吐上升，并且在同样吞吐的情况下，网关的 CPU 能够下降 50% 以上，而请求耗时下降 30% 左右。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*MXSySoRPsJ4AAAAAAAAAAAAADrGAAQ/original)
+
+### 容器调度引擎
+
+HUSE 容器调度引擎，作为蚂蚁容器调度引擎的下一代架构，是专门面向高吞吐、低延迟、低成本、急速启动的 Serverleess 场景而设计的。目前应用在 FaaS 场景，以及一些 batch job、ODPS、大数据等场景。
+
+为了能够实现高吞吐、低延迟等功能，HUSE 提供了如：多级自适应缓存、高速的协议通讯栈、智能包加载等性能优化，同时也支持高可用和自运维功能。
+
+在性能上，可以看到 HUSE 容器调度引擎的性能数据，在全集群 1 万 QPS 吞吐压力下，整个 HUSE 的调度耗时 P50 基本上在 21ms 左右，P99 在 50ms 以内。相比于传统的容器调度引擎，有着数量级级别的提升。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*orW8SqxQBxsAAAAAAAAAAAAADrGAAQ/original)
+
+全集群 10000 QPS 调度吞吐下，HUSE 可以实现平均 21ms 的容器调度延迟  
+
+### 100ms 函数容器冷启动 
+
+最后也最重要的一部分，函数容器冷启动性能优化实践。虽然在服务端也做了一些优化，但是服务端整理的耗时本身也不过几毫秒，可优化空间很小。因此整个函数请求耗时的大头还是在函数容器的冷启动上。而关于函数容器冷启动，有四个方面可以进行性能优化。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*UOiFRKX-y0EAAAAAAAAAAAAADrGAAQ/original)
+
+第一，是**从 Warm P** **ool 模式变成完全的冷启动**。在并发的场景下，cache 技术本身也会占用 CPU 核数和计算资源，并不会有太多的性能提升。
+
+第二，**容器资源实时分配改为缓存资源**。容器运行依赖一些资源，比如 IP，下载镜像，挂载 volume，设置 cgroup 和 namespace 等。这些资源分配都很慢，基本是分钟级别。而蚂蚁 FaaS 对容器所依赖的所有资源，只要不占用 CPU 和 Mem 的话，都会对其进行缓存，最终将资源分配的速度做到 0ms。
+
+第三，传统的文件系统，创建、挂载以及访问都比较慢，蚂蚁 FaaS **采用 ROFS 的文件格式**，即 Read Only File System 的方式去进行优化。
+
+第四，是**容器的启动方式**。标准的 OCI 容器的启动方式是 create+ start，启动速度很慢，而蚂蚁 FaaS 采用了 **checkpoint+restore** 技术进行性能优化。
+
+#### 蚂蚁函数运行时介绍
+
+容器运行时分为 runC、runD 和 runSC 等不同类型。runC 的安全隔离太差，runD 的启动速度太慢并且资源消耗太高，都不适合 FaaS 的场景。NanoVisor 是蚂蚁 runSC 安全容器。它是 Go 语言编写的安全容器，重构于开源的 gVisor 项目，是为云原生设计优化的、弹性安全容器。它也是轻量级 HyperVisor，进行 syscall interception 和 host syscall 加速。支持多个平台的运行，同时在性能方面尤为出色，可以支持一些火焰图性能分析，并且对 Go Runtime 进行优化，同时引入了高性能的用户态协议栈。目前应用在 FaaS 和一些增强安全的场景。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*x4_qS5nV5YUAAAAAAAAAAAAADrGAAQ/original)
+
+#### ROFS 文件系统优化 
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*GC4iRa3gfXMAAAAAAAAAAAAADrGAAQ/original)
+
+上图中可以看到，一个容器会有两个进程， runSC Sandbox 进程和 Gofer 进程，容器镜像解压成 Rootfs 文件 bindmount 到 Gofer 进程中，用户函数代码也一样。Sandbox 需要访问函数和系统文件，需要经过 syscall 然后被 Gofer 进程拦截和控制。这种方式是为了保证安全，但是多了一个进程占用 CPU 核数，同时函数访问系统文件都需要进行 syscall ，拉低了速度。
+
+ROFS 文件系统优化，就是将镜像和用户代码都编译成 ROFS 可以解析的格式，并且在沙箱外部打开。同时通过 mmap() 映射到沙箱进程中去。通过这样的方式，可以降低一半的 CPU 占用，同时所有文件的操作都变成了内存操作。不仅更加快速，而且更加安全。  
+
+#### 容器启动方式优化 
+
+一个标准的 OCI 容器会提供两个相关的接口：create 和 start。create 是根据容器镜像和配置文件创建容器运行的环境，对应 NanoVisor 容器沙箱的创建和应用程序内核的初始化；start 则是启动容器，对应 NanoVisor 容器沙箱内一号进程(*Nodejs Runtime*)的创建和启动。这个过程非常慢。
+
+蚂蚁 FaaS 采用的是 checkpoint + restore 方式进行容器的恢复。首先按照传统方式创建、启动一个容器，等待容器内的 Nodejs Runtime 初始化完成之后，使用 checkpoint 技术对 Nodejs Runtime 进程和应用程序内核 sentry 进行状态、数据的保存。可以理解为对整个容器进行了一个内存快照，然后导出 checkpoint.img 的种子文件。这样的话，下一次有请求过来，直接从 checkpoint.img 种子恢复函数容器，也就是 restore 的过程。所以 restore 就是直接利用之前保存好的进程、内核状态和数据进行恢复，不再需要重新初始化 Nodejs Runtime。在恢复完成之后，Nodejs Runtime 就可以立刻进行业务逻辑处理。
+
+通过以上的优化，目前 FaaS 函数容器落地的启动速度达到了 90ms 以内，额外的内存开销要小于一兆，这一提升相当可观。其中使用到的 NanoVisor 作为蚂蚁的第三代安全容器，始于安全。因此之后可以期待在性能提高和成本缩减上能够做到十倍甚至百倍的一个提升。
+
+目前业界的类似产品中，AWS Lambda 函数的冷启动性能是比较好的：在 Node.js 运行时环境，平均冷启动时间为 200ms。
+
+需要注意的是，此数据仅供参考，实际情况会受多种因素影响。
+
+## 安全能力建设
+
+性能优化的同时，安全功能也必须得到保障。以蚂蚁 FaaS 安全功能的建设为参考。函数容器(*runSC Sandbox*)是一个完全隔离的 runSC 沙箱环境，配置有 ACL 规则和虚拟的 veth pair 网卡。这个网卡是完全虚拟的，没有任何意义，而且在 FaaS 的场景下基础设施从设计上本身就是透明的。网卡的另一端插在 bridge 网桥设备上，并且通过 eBPF 进行高效的网络过滤、控制和转发。因此整个函数容器沙箱是完全隔离的。
+
+### 纵向容器防逃逸 
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*sL-oTKdXefgAAAAAAAAAAAAADrGAAQ/original)
+
+函数程序运行在虚拟化的 guest 态，它的系统调用会被 sentry（*运行在 Guest Kernel 态和 Host Kernel 态*) 也就是 NanoVisor 处理和响应。NanoVisor 运行在 Guest Kernel 态和 Host Kernel 态， 处理所有函数实例的系统调用，进行限制和管控。同时 NanoVisor sentry 本身的系统调用也会由 seccomp 进行限制。
+
+FaaS 的场景基本隔离掉了基础设施信息，因此限制的接口会更多，攻击面会更小更安全。同时 NanoVisor 提供进程级别的 NanoVM 虚拟化技术，是一个轻量级的 VMM 管理，作为 host 上的一个内核模块，可以有效保障内核安全。  
+
+### 横向安全能力 
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*CADWRYu8K9MAAAAAAAAAAAAADrGAAQ/original)
+
+在横向控制上，NanoVisor 也做了很多能力建设，包括对所有的网络操作，包括 accept 一些端口、监听 DNS 请求等，都会进行网络审计。同时基于四层网络的五元组信息，都可以进行 ACL 控制。
+
+### 免鉴权调用  
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*4v1mSo_cUQsAAAAAAAAAAAAADrGAAQ/original)
+
+隔离之外，互通也值得关注。所有函数都通过函数网关进入，但是用户函数代码也需要访问其他的服务。一些场景比如函数代码里面可以访问其他的函数、访问云服务、访问 DB 和 OSS 等，或者访问公网，或者访问多云的 VPC 或者 IVS 的 VPC。
+
+在这样的情况下，蚂蚁 FaaS 建设了对应的代理服务和网络设备，在四层为这些服务打开 ACL 控制，同时会在七层进行应用层的认证和授权。认证和授权的过程完全由 runtime 和代理服务实现，整个过程对开发者是完全透明和无感的。所以开发者也不需要设置 IP、账号/密码等信息，这样可以最大限制地屏蔽中间件、基础设施和多云的干扰。
+
+# 体验 
+
+有着这样的整体架构，再加上性能的优化实践和安全能力建设，蚂蚁 FaaS 的产品使用体验是什么样的呢？
+
+**研发态的体验：** 从创建函数到编写函数到执行函数，基本上几秒钟就能够完成一个函数代码的上线。和传统应用模式对比鲜明，不需要去申请应用创建代码仓库，编写代码，编译打包等。曾经在 7 月的一次活动中，一个六年级的小朋友现场花 5 分钟，就完成了整个支付宝小程序+FaaS 云函数的开发。
+
+**运维体验：** 由于整个蚂蚁 FaaS 的设计都是符合 Serverless 理念，所以这里看不到任何基础设施信息，但是可观测性相关的链路日志指标告警是完全具备的。作为 Serverless 的一站式免运维的平台，它能够自动集成监控和告警功能。
+
+# 总结 
+
+总之，蚂蚁 FaaS 的改变和优势在于：
+
+-   从成本上来说，更小内存开销、更快启动速度。用户只用为流量付费，甚至只用为其函数代码的运行时间付费。（而运行时间可压缩至一个毫秒。）
+-   更高保的安全隔离，能够进行免鉴权的调用。更快的研发速度、更高效的运维。
+-   可以快速开发，没有复杂的流程，也没有碎片化的代码版本的困扰。
+-   完全 Serverless 一站式免运维平台，能够集成监控和告警。
+
+# 展望：FaaS + AI 开启编程新纪元 
+
+蚂蚁 FaaS 对未来的展望包括对**极致性能**与**极致效能**的追求，将通过 fork 等技术去实现更高的性能，同时通过 AIGC 等智能化方式去达到极致研发效能。
+
+## 极致性能 
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*Ztx3TL5_v90AAAAAAAAAAAAADrGAAQ/original)
+
+在极致性能的实现中，蚂蚁目前正在调研的 fork 技术，函数冷启动时间已经达到了 3.5ms，稳定地跑进 10ms 以内。有着这样的启动速度，函数容器的创建跟创建一个线程一样又快、开销又低。同时 fork 技术还可以进行和 runtime、和 user code 的组合，让启动再加速。
+
+## 极致效能 
+
+追求极致效能的方式，就是 FaaS+AI。在文章最开始，可以看到 ChatGPT 生成的一段函数代码，只要十几行代码就可以完成一个业务逻辑的处理。所以 AIGC+FaaS 并非纸上谈兵，而是很有前景的，并且将会在不远的未来落地实践。AI+函数开发模式会结合一些低代码平台，并且利用蚂蚁集团的 NLP GPT/ Code GPT/ OpsGPT 等智能化平台，去演进和诞生一些新的产品形态和编程体验。想象未来 PD 或运营通过自然语言，和 AI 平台沟通，由 AI 平台生成一些格式化的 PRD，再输入到类似低代码/无代码的平台，平台一方面集成 AI 的代码生成能力，一方面集成 FaaS 的 Serverless 功能，这样将大大提高研发效能。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*QgjqTJplFygAAAAAAAAAAAAADrGAAQ/original)
+
+在过去的几年里，云原生技术已经改变了整个运维体验。但是直到今天，研发模式持续了二十多年，还是一成不变，开发者们还是在电脑面前苦哈哈地敲着键盘。希望未来 FaaS+AI 能开启编程新纪元，颠覆整个研发体验。
+
+# FaaS 延伸支付宝云开发 
+
+FaaS 技术体系在蚂蚁已经十分成熟，今年基于蚂蚁 FaaS 技术体系沉淀，打造了一款支付宝小程序云开发产品，欢迎大家了解试用。
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*fTDAS6IyYVsAAAAAAAAAAAAADrGAAQ/original)
+
+欢迎大家扫描下方👇二维码，或搜索钉钉群号：*25600034150*，加入支付宝云开发钉钉支持群了解试用：
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*S_7nTb9cKq0AAAAAAAAAAAAADrGAAQ/original)
+
+产品官网：[https://cloud.alipay.com/main/product/cloudbase](https://cloud.alipay.com/main/product/cloudbase)
+
+# 推荐阅读
+
+1、[如何看待 Dapr、Layotto 这种多运行时架构？](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247510516&idx=1&sn=eff21915cd0ac1a8c8e3f126b549a605&chksm=faa3462ecdd4cf38ab6ab0c7201902fb53d54cea4865f9b7d7cdcdc7eaa00cf354d8b05e5393&scene=21)
+
+2、[Service Mesh 的下一站是 Sidecarless 吗？](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247517361&idx=1&sn=9a5947c97d2e6adffa3d066c4c599c7b&chksm=faa36b6bcdd4e27dac0d925ac6385de906b413944203519f7b9be627b0b708e87381f0bcad2b&scene=21)
+
+3、[MoE 系列（七）｜ Envoy Go 扩展之沙箱安全](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247538840&idx=1&sn=62286a02933ffae587479586b39ce3c1&chksm=faa3b742cdd43e5427fd1b2a44e8ded825a413f867ed3eb62451c18e2a0ea9cfcf1d703c4513&scene=21)
+
+4、[Seata-DTX｜分布式事务金融场景案例介绍](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247537905&idx=1&sn=a92e6aa6ac60fe23b6a21043777c7aa7&chksm=faa3bb2bcdd4323d2470977f715f383ec3bf10b610a7467ebb4ae6e6ddbb7cb2f8f87766de55&scene=21)
diff --git a/content/zh/blog/dragonfly-v-2-1-0-release/index.md b/content/zh/blog/dragonfly-v-2-1-0-release/index.md
new file mode 100644
index 000000000..bd7b4812f
--- /dev/null
+++ b/content/zh/blog/dragonfly-v-2-1-0-release/index.md
@@ -0,0 +1,133 @@
+---
+title: "Dragonfly 发布 v2.1.0 版本！"
+authorlink: "https://github.com/sofastack"
+description: "Dragonfly 发布 v2.1.0 版本！"
+categories: "SOFAStack"
+tags: ["SOFAStack"]
+date: 2023-08-08T15:00:00+08:00
+cover: "https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*4tMSTYU5lBwAAAAAAAAAAAAADrGAAQ/original"
+---
+
+**Dragonfly 最新正式版本 v2.1.0 已经发布！** 感谢赵鑫鑫[1]同学帮助重构 Console 代码，并且提供全新的 Console[2]控制台方便用户可视化操作 P2P 集群。欢迎访问 d7y.io[3]网站来了解详情，下面具体介绍 v2.1.0 版本带来了哪些更新。
+
+![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6169c0485e0143588a9a43248c50e612~tplv-k3u1fbpfcp-zoom-1.image)
+
+## 功能
+
+-   Console v1.0.0[4]已经发布，它是一个全新的可视化控制台，方便用户操作 P2P 集群。
+-   新增虚拟网络拓扑探索功能，能够在 P2P 运行时探测节点之间的网络延迟，从而构建一个虚拟网络拓扑结构提供调度使用。
+-   Manager 提供控制 Scheduler 可以提供的服务，例如在 Manager 中设置 Scheduler 不提供预热功能，那么 Scheduler 实例就会拒绝预热请求。
+-   `Dfstore` 提供 `GetObjectMetadatas` 和 `CopyObject` 接口，支持 Dragonfly 作为 JuiceFS 的后端存储。
+-   新增 `Personal Access Tokens` 功能，用户可以创建自己的 `Personal Access Tokens` 在调用 Open API 的时候鉴权使用。
+-   Manager REST 服务提供 TLS 配置。
+-   修复当 Dfdaemon 没有可用的 Scheduler 地址时启动失败的现象。
+-   新增 `Cluster` 资源单位，`Cluster` 代表一个 P2P 集群，其只包含一个 `Scheduler Cluster` 和一个 `Seed Peer Cluster`，并且二者关联。
+-   修复 `Dfstore` 在 Dfdaemon 并发下载时，可能导致的对象存储下载失败。
+-   Scheduler 新增 Database 配置，并且把之前 Redis 的配置信息移入到 Database 配置中，并且兼容老版本。
+-   在 Dfdaemon 中使用 gRPC 健康检查代替 `net.Dial`。
+-   修复调度器过滤以及评估过程中 `candidateParentLimit` 可能影响到调度结果的问题。
+-   修复 Scheduler 中的 Storage 在 `bufferSize` 为 0 的时候，导致的无法写入下载记录的问题。
+-   日志中隐藏敏感信息，例如 Header 中的一些 Token 信息等。
+-   Manager 中 Scheduler、Seed Peer 等资源删除过程中，不再使用软删除。
+-   Scheduler 数据库表中新增 `uk_scheduler` 索引，Seed Peer 数据库表中新增 `uk_seed_peer` 索引。
+-   由于初期功能设计定位不清晰的原因，删除 `Security Domain` 和 `Security` 的功能。
+-   Manager 和 Scheduler 新增 Advertise Port 配置，方便用户配置不同的 Advertise Port。
+-   修复 Task 注册阶段状态机状态变更错误的问题。
+
+## 破坏性变更
+
+-   不再提供 Scheduler Cluster 和 Seed Peer Cluster 之间 `M:N` 的关系。提供了 Cluster 的概念，一个 Cluster 即表示一个 P2P 集群，并且一个 Cluster 只包含一个 Scheduler Cluster 和 Seed Peer Cluster，且二者是 `1:1` 的关联关系。
+
+## 控制台
+
+![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/af38313a8e5c4806b29838143b99b934~tplv-k3u1fbpfcp-zoom-1.image)
+
+更多的关于控制台的内容可以参考官网文档 Manager Console[5]。
+
+## AI 基础设施
+
+-   Triton Inference Server[6]使用 Dragonfly 下载模型文件，可以参考 #2185[7]。如果有对集成 Triton Inference Server 项目 Drgaonfly Repository Agent[8]感兴趣的同学，可以联系 gaius.qi@gmail.com。
+-   TorchServer[9]使用 Dragonfly 下载模型文件，现正在开发，预计 v2.1.1 版本可以使用，项目仓库在  Dragonfly Endpoint[10]。
+-   Fluid[11]基于 JuiceFS[12]运行时通过 Dragonfly 下载数据，正在开发，预计 v2.1.1 版本可以使用。
+-   Dragonfly 助力火山引擎 AIGC [13]推理业务 P2P 镜像加速。
+-   社区中已经有很多案例，基于 P2P 技术使用 Dragonfly 分发 AI 场景中的文件。在 AI 推理阶段，推理服务并发下载模型可以有效通过 Dragonfly P2P 缓解模型仓库的带宽压力，从而提高整体下载速度。在 KubeCon + CloudNativeCon + Open Source Summit China 2023[14]社区联合快手做一次分享，主题是《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group & Zekun Liu, Kuaishou Technology》[15]，感兴趣的同学可以关注。
+
+## 维护者
+
+社区新增四位 Maintainer，希望能够帮助更多的 Contributor 参与到社区的工作中。
+
+-   黄逸炀[16]：就职于火山引擎，主要专注于社区代码工程方面。
+-   温满祥[17]：就职于百度，主要专注于社区代码工程方面。
+-   Mohammed Farooq[18]：就职于 Intel，主要专注于社区代码工程方面。
+-   许洲[19]：大连理工大学在读博士，主要专注于智能调度算法方面。
+
+## 其他
+
+版本更新包含的更多细节可以参考👇 
+
+CHANGELOG：[https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md](https://github.com/dragonflyoss/Dragonfly2/blob/main/CHANGELOG.md)
+
+## 相关链接
+
+[1].Xinxin Zhao Github：
+
+[https://github.com/1zhaoxinxin](https://github.com/1zhaoxinxin)
+
+[2].Dragonfly Console Github：
+
+[https://github.com/dragonflyoss/console](https://github.com/dragonflyoss/console)
+
+[3].Dragonfly 官网：
+[https://d7y.io](https://d7y.io)
+
+[4].Dragonfly Console Release v1.0.0：
+[https://github.com/dragonflyoss/console/tree/release-1.0.0](https://github.com/dragonflyoss/console/tree/release-1.0.0)
+
+[5].Manager Console 文档：
+[https://d7y.io/docs/reference/manage-console](https://d7y.io/docs/reference/manage-console)
+
+[6].Triton Inference Server：
+[https://github.com/triton-inference-server/server](https://github.com/triton-inference-server/server)
+
+[7].issue #2185：
+[https://github.com/dragonflyoss/Dragonfly2/issues/2185](https://github.com/dragonflyoss/Dragonfly2/issues/2185)
+
+[8].Dragonfly Repository Agent Github：
+[https://github.com/dragonflyoss/dragonfly-repository-agent](https://github.com/dragonflyoss/dragonfly-repository-agent)
+
+[9].TorchServe：
+[https://github.com/pytorch/serve](https://github.com/pytorch/serve)
+
+[10].Dragonfly Endpoint Github：
+[https://github.com/dragonflyoss/dragonfly-endpoint](https://github.com/dragonflyoss/dragonfly-endpoint)
+
+[11].Fluid：
+[https://github.com/fluid-cloudnative/fluid](https://github.com/fluid-cloudnative/fluid)
+
+[12].JuiceFS：
+[https://github.com/juicedata/juicefs](https://github.com/juicedata/juicefs)
+
+[13].Volcano Engine AIGC：
+[https://mp.weixin.qq.com/s/kY6DxRFspAgOO23Na4dvTQ](https://mp.weixin.qq.com/s/kY6DxRFspAgOO23Na4dvTQ)
+
+[14].KubeCon + CloudNativeCon + Open Source Summit China 2023：
+[https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/](https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/)
+
+[15].《Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group & Zekun Liu, Kuaishou Technology》：
+[https://sched.co/1PTJb](https://sched.co/1PTJb)
+
+[16].Yiyang Huang Github：
+[https://github.com/hyy0322](https://github.com/hyy0322)
+
+[17].Manxiang Wen Github：
+[https://github.com/garenwen](https://github.com/garenwen)
+
+[18].mfarooq-intel Github：
+[https://github.com/mfarooq-intel](https://github.com/mfarooq-intel)
+
+[19].Zhou Xu Github：
+[https://github.com/fcgxz2003](https://github.com/fcgxz2003)
+
+## Dragonfly Star 一下✨：
+
+[https://github.com/dragonflyoss/Dragonfly2](https://github.com/dragonflyoss/Dragonfly2)
diff --git a/content/zh/blog/sofa-weekly-20230818/index.md b/content/zh/blog/sofa-weekly-20230818/index.md
new file mode 100644
index 000000000..c5d61d9a4
--- /dev/null
+++ b/content/zh/blog/sofa-weekly-20230818/index.md
@@ -0,0 +1,89 @@
+---
+title: "SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献"
+authorlink: "https://github.com/sofastack"
+description: "SOFA Weekly｜Layotto 社区会议回顾与预告、SOFA 茶水间、社区本周贡献"
+categories: "SOFA Weekly"
+tags: ["SOFA Weekly"]
+date: 2023-08-18T15:00:00+08:00
+cover: "https://gw.alipayobjects.com/mdn/sofastack/afts/img/A*NAHaRrQqGzAAAAAAAAAAAAAAARQnAQ"
+---
+
+## SOFA WEEKLY | 每周精选
+
+![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1e08fca65f7643c783d33f590bb41d5a~tplv-k3u1fbpfcp-zoom-1.image)
+
+**筛选每周精华问答，同步开源进展，欢迎留言互动～**
+
+**SOFA**Stack（**S**calable **O**pen **F**inancial **A**rchitecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。
+
+**SOFAStack 官网:** [https://www.sofastack.tech](https://www.sofastack.tech)
+
+**SOFAStack:** [https://github.com/sofastack](https://github.com/sofastack)
+
+## SOFA 社区会议预告
+
+**Layotto：**
+
+**主题：** Layotto 社区会议
+
+**时间：** 08 月 23 日 14:00 - 15:00
+
+**入会口令（钉钉）：** 688 824 34655
+
+电话呼入：+057128095818（中国大陆）+02162681677（中国大陆）
+
+入会链接：[https://meeting.dingtalk.com/j/KPX3eRflTbk](https://meeting.dingtalk.com/j/KPX3eRflTbk)
+
+**议题：**
+
+Layotto 项目规划和展望 #976
+
+2023 开源之夏-课题汇总 #894
+
+OSPP | Layotto 支持 Pluggable Component 组件 #959
+
+Support Pod Injection to deploy Layotto as a sidecar in Kubernetes #910
+
+Develop a new component for sms API；为“短信 API”开发新的组件 #830
+
+Discuss: whether the sms API definition needs to be modified；讨论一下是否需要修改 sms API 定义 #966
+
+「**Layotto**」：[https://github.com/mosn/layotto/issues/981](https://github.com/mosn/layotto/issues/981)
+
+## SOFA 社区会议回顾
+
+**Layotto：**
+
+**主题**：Layotto 社区会议
+
+**时间**：8 月 16 日 14:00 - 15:00
+
+**会议内容**：
+
+Layotto 公有云部署想法、下半年产品演进路线讨论分析；
+
+开源之夏进展同步：
+
+可插拔插件初步方案的讨论；
+
+K8s 集成注入位置确认、Dapr 注入的实现方案讨论；
+
+短信 API 适应不同场景的设计方案
+
+「**Layotto**」：[https://github.com/mosn/layotto/issues/981](https://github.com/mosn/layotto/issues/981)
+
+「**会议回放**」：[https://www.bilibili.com/video/BV1wX4y1E7KQ/](https://www.bilibili.com/video/BV1cm4y1W7jH)
+
+## SOFAStack 社区本周贡献
+
+![图片](https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*0NT-TbiIfHgAAAAAAAAAAAAADrGAAQ/original)
+
+## 本周推荐阅读
+
+[超越边界：FaaS 的应用实践和未来展望](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247539068&idx=1&sn=df83153437d75a7c0b12360066480b49&chksm=faa3b6a6cdd43fb0159ecd2152dc4614c9c9d8003a3423c6c9833c7f19afbfadade59641edae&scene=21)
+
+[MoE 系列（七）｜ Envoy Go 扩展之沙箱安全](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247538840&idx=1&sn=62286a02933ffae587479586b39ce3c1&chksm=faa3b742cdd43e5427fd1b2a44e8ded825a413f867ed3eb62451c18e2a0ea9cfcf1d703c4513&scene=21)
+
+[SOFABoot 4.0 正式发布，多项新特性等你来体验！](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247538370&idx=1&sn=d6dd2814c3341825fe9b3abc9d8158e7&chksm=faa3b918cdd4300e8a423e4018374b51bd55d1947235aa3efed0c3f0532401e37b7d04079e6e&scene=21)
+
+[Seata-DTX｜分布式事务金融场景案例介绍](https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247539113&idx=1&sn=80e425391219e3d3044b493f6d863b93&chksm=faa3b673cdd43f6552c562910419af0d7becf8aa292d49bf0d1f198c61b7efd172b4e02decc6&cur_album_id=2674373532445081604&scene=189)
diff --git a/layouts/partials/post/article.html b/layouts/partials/post/article.html
index c2e840561..08f270eea 100644
--- a/layouts/partials/post/article.html
+++ b/layouts/partials/post/article.html
@@ -1,3 +1,22 @@
 <article class="typo">
-	{{ .Content | markdownify }}
-</article>
\ No newline at end of file
+  {{ .Content | markdownify }}
+</article>
+
+<script>
+  const article = document.querySelector('article.typo')
+
+  // 选取所有img标签
+  const imgElements = article.querySelectorAll('img');
+
+  // 遍历img标签数组
+  imgElements.forEach(img => {
+    // 获取img标签的src属性值
+    const src = img.getAttribute('src');
+
+    //拼接变量
+    const newSrc = '//images.weserv.nl/?url=' + src;
+
+    // 修改img标签的src属性
+    img.setAttribute('src', newSrc);
+  });
+</script>
\ No newline at end of file