城市商业焦点不断轮换，越来越多的社区商业通过提供多元社区服务与消费场景被人们所追捧。以社区商业发达的东南亚国家为例，新加坡多年来探索的邻里中心概念被全球所借鉴、泰国以共享友好型开放公共空间理念打造了一众全球社区商业典范......
回望国内，城市化进程的推进让中国有了更多的城市新区和更多等待发掘的消费市场，以便民、利民，满足居民综合消费为宗旨的属地型商业，成为居民能在家门口锁住烟火气的生活小确幸。据赢商网不完全统计，2021年中国社区服务消费为13.5万亿元，社区商业已然形成万亿级消费市场。未来10年，我国社区商业消费将逐渐占到社会消费零售总额的1/3，还将预计形成2万个以上新社区。
打开网易新闻 查看精彩图片
◎西安航天城夜景
面对巨大的消费需求，商业人开始以人本化、在地化、生态化为价值导向，以“邻里中心”的概念构建新型城市功能单元，将商业项目打造成社区全生活链服务的平台。在具备“高效、便利、协作、灵动”的特质之外，打造能够输出持续生长力和沸腾生活感的复合型社区商业新生态成为新的发力点。如今，航天城·真珠港购物中心正在这个新赛道上不断探索尝试，也为航天城的社区商业发展找到新的答案。
抢滩航天中心区
重塑社区商业封面
城市发展一路向南，西安航天基地北与曲江为邻，南抵少陵塬畔，区位优势得天独厚。凭借陕西航天工业雄厚的综合实力和坚实的发展基础，被国务院批复为国家级陕西航天经济技术开发区，随着一期的综合提升及二期的快速发展，目前已成为公共基础设施配套完善，产业集群优势明显，产城融合的城市综合服务区，其承接曲江产业外溢的要冲之地功能也被发掘，更是西安建设国家中心城市的重要功能承载区。
// 区域发展进入快车道，航天城商业迎来黄金窗口期
在与城市经济深度融合的快车道上，航天城的人气值不断攀升，成为西安人眼中的网红区域，宜居宜业不再是一句口号，而是区域内真实的需求呼声。多方利好的加持为第三产业更新区域界面提供了便利，也让航天城商业发展迎来黄金窗口期。
打开网易新闻 查看精彩图片
◎西安航天城街景
面对当下区域内大多社区商业经营业态没有专业规划，无法保障运营的统一性与品质感的状况，一个可以定制业态、把控品牌水平的一站式邻里型商业中心成为供、需双方共同期待的商业平台。
也正因如此，航天城·真珠港购物中心的出现为航天城板块内社区商业的发展塑造了一个更高水准的样板，提供了更多新的思路。
打开网易新闻 查看精彩图片
◎航天城·真珠港购物中心效果图
// 20万客群、近百个社区，区域商业亟待突破发展
具体来看，航天城·真珠港购物中心位于航天大道与神州五路交叉口，与地铁四号线航天大道站无缝对接。项目总面积7万㎡，实际经营面积达4万㎡，分为地下两层，地上六层，集合周边零散的商业形式为一体，提供聚餐、娱乐、儿童体验、购物等一站式体验。据悉，项目分两期建设，一期将于今年开业，二期则主打生活配套，正在紧密筹备中。
打开网易新闻 查看精彩图片
调研数据显示，周边2km常住人口20万，覆盖49个住宅小区和29个写字楼，中小学、培训等教育配套达171个，且周边以高端改善型住宅为主，不仅有成熟社区富力城，还可辐射大华曲江公园世家、碧桂园云顶、山水领袖、万科城市之光，科为?城墅等高端社区，客群具有一定的消费实力且对生活品质有所追求，未来这里还将吸引数万商住群体入驻，一大批品质消费者将潮聚于此。
先社区再商业
打造新一代邻里生活中心
在当前的城市住宅形态面前，邻里间的关系过于平淡，人们迫切需要一处家以外的“第二客厅”，来形成一个既保障了家庭私密性，又可以加强邻里间情感链接的开放社交场所。在航天城·真珠港购物中心看来，社区商业正是“家的延伸”，是“社区社交生活中心”，重在突出生活化、社交性、体验感，强化服务性功能。
因此，航天城·真珠港购物中心不做“社区内的商业”，而是要做“服务于社区的商业”，摒弃传统社区底商沿街为市的粗放型商业形态，立足于各类社区服务，紧抓消费者对服务品质、社交体验的需求，将辐射范围内的市场做深做透。
打开网易新闻 查看精彩图片
◎航天城·真珠港购物中心效果图
// 聚焦品质生活，打造家庭第二客厅
对航天城·真珠港购物中心来说，经营社区商业，就是经营邻里关系。新一代社区商业，正在化身家之外的“第二客厅”，是“遛娃后花园”，是有温度的邻里生活枢纽，更是社区品质社交中心。航天城·真珠港购物中心聚焦社区居民，包括上到老人，下到母婴的全龄客群在生活、饮食、亲子、运动的“家门口”消费需求，将通过贴合不同社区群体的时间习惯，全客层全时段运营：从晨练、早餐的“晨经济”，到深夜食堂的“夜经济”，从托育、健身“周中经济”到娱乐、购物的“周末经济”，7×24为周边社区居民带来创新多元的购物娱乐体验，把对未来邻里生活的构思一点点落到实处，让社区商业以全新的面貌展现在大众眼前。
据悉，航天城·真珠港购物中心在业态配置与品牌选择上更加突出便捷性、品质感、社交性和独创性，围绕不同的目标群体和生活场景进行布局，构建全生活业态，让不同社区居民都能找到适配的产品与服务。
打开网易新闻 查看精彩图片
◎航天城·真珠港购物中心效果图
B1层以“生活地”为主题，搭配品质型零售超市、小餐饮及生活服务类品牌；L1、L2层以“轻奢港”、“精致馆”构建时尚零售区域，引入珠宝美妆、咖啡烘焙、汽车展厅及3C数码等精品零售；L3层围绕“乐趣湾”主题聚集儿童、文创、户外运动、家居等业态；L4、L5主打“宴会厅”、“烟火街”主题，布局多元餐饮、KTV等人气品牌；L6层则聚焦绿色、健康，打造屋顶花园餐厅并引入竞技体育等强体验、社交业态。
此外，考虑到周边居民的出行便利性，航天城·真珠港购物中心不仅在B2层提供1500+停车位，包含智能车位和新能源车位，停车场外还规划了非机动车停放区域，以及外卖车辆通道等，所有举措只为给予社区更加便利的生活。
// 社区商业“升级”，在地融合营造新看点
“相比于传统购物中心，社区商业在社会性质上，更切实贴合人与人的“社区共同体”，植根于居民空间并影响周围环境，反哺生活在这片社区中的人们。”在地社区融合的商业理念，正在成为越来越多商业体做社区运营的宗旨。
在航天城·真珠港购物中心项目上，我们也看到了这样的理念运用。多元且注重品质的业态组合、重视“邻里关系”的公共空间，深度参与大社区文化营造，成为在地居民美好生活的“建设者、参与者与服务提供者”等等，都是航天城·真珠港购物中心对“美好邻里赋能港”思考的产物。
打开网易新闻 查看精彩图片
◎航天城·真珠港购物中心效果图
在“美好邻里赋能港”的背后，航天城·真珠港购物中心更像是人与商业的粘合剂，以实现消费者对美好生活方式的追求为使命，向顾客的消费偏好看齐并提供品质内容，引领区域商业不断进阶。
“活化”区域生活方式
构筑独具温度的商业肌理
以往社区商业的核心是通过提供快捷、方便的目的性服务，满足人们高频、刚性消费需求。但随着消费价值逐渐从功能价值向社会价值、情感价值和认知价值开始倾斜，社区商业已经从功能型消费业态升级为陪伴型消费业态，更强调与区域人群的共同成长、情感联系与价值共鸣。
// 放大情感诉求，亲朋好友的社交部落
无论是对于老年人还是新兴起的Z世代，如何通过社交融入社会，都会是他们值得考虑的刚需。航天城·真珠港购物中心以此为抓手，放大消费者的情感诉求，结合项目本身场地优势，将在室外停车场地打造航天城最大复古市集---真珠港城南LOCAL大集，用潮流复古氛围还原出记忆里的市井摆摊场景，以近百家小商品一月一次的航天“月会”，满足不同年龄段消费者的游逛需求、社交需求。
此外，伴随“它经济”的悄然兴起，铲屎官阵容逐渐壮大，诸多商业项目都将“它经济”作为引流和体现差异化的亮点，航天城·真珠港购物中心洞察这一客群需求，为周边居民解除遛宠烦恼，打造宠物友好商场，从硬件设施到软性服务双向发力，为会员提供爱宠免费基础护理服务的同时，兼顾普通消费者的购物体验，打造人宠和谐相处的消费环境。
打开网易新闻 查看精彩图片
◎航天城·真珠港购物中心效果图
// 家门口的“诗和远方”，共创社区公共文化空间
有生命力的商业，并不是在于有望其项背的体量，或者高不可攀的业态，亦或是极具商业化的建筑形式，而在于以长期主义根植于肌体内的，不断焕新的内容血液和更迭的潮流玩法。
航天城·真珠港购物中心深谙如此，牢记其深耕社区的属性，紧抓社群私域流量，提供公共活动空间，通过共享空间的设计深化社交场景服务。譬如，航天城·真珠港购物中心处于主城区通往长安的主要路段，无论是进秦岭、峪口还是生态公园，都有大量游客途经此地，未来极易成为旅途中的能量补给站。利用项目区位优势，航天城·真珠港购物中心将为出行人群提供傍晚驿站，以及房车旅行的补给，并通过开阔的地上停车场地不定期组织氛围活动让各地旅行发烧友在此交流、互动，实现圈层文化传播。
不难发现，航天城·真珠港购物中心从人们的生活日常出发，以生活场景、符合定位的业态矩阵，以及代表年轻生活方式的创意营销活动，联结起身边一切有趣的人、事、物；并作为复合多元空间中的一部分，融入更多的城市机能，重新构建城市、社区与人的亲密关系，激发生活灵感，为航天城注入别样的商业DNA。
图片源于：航天城·真珠港购物中心、视觉中国
特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。

文｜周群力（花名：仪式 )
Layotto PMC Layotto 和 SOFAStack 开源社区的建设，Dapr 贡献者，Dapr sig-api 的 Co-chair
本文 10963 字 阅读 20 分钟
2019 年，微软开源了 Dapr 项目。2021 年，蚂蚁参照 Dapr 思想开源了 Layotto 项目。如今，蚂蚁已落地 Layotto，服务了很多应用。从理想落地到现实的过程中，我们遇到了不少问题，也对项目做了很多改变。回过头再看，如何看待 Dapr、Layotto 这种多运行时架构？我们能从中学到什么？
本次我将从以下几个方面，分享蚂蚁在落地多运行时架构之后的思考：
1. 如何看待“可移植性”
2. 多运行时架构能带来哪些价值
3. 与 Service Mesh、Event Mesh 的区别
4. 如何看待不同的部署形态
PART. 1 快速回顾
如果你熟悉 Multi-Runtime、Dapr 和 Layotto 的概念，可以跳过这一章节，直接进入下一章节。
快速回顾：什么是 Multi-Runtime 架构？
Multi-Runtime 是一种服务端架构思路，如果用一句话来概括，就是把应用里的所有中间件挪到 Sidecar 里，使得“业务运行时”和“技术运行时”分离开。
更详细的解释如下：首先来看 Service Mesh，和传统 RPC 框架相比，Service Mesh 的创新之处在于引入了 Sidecar 模式。Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立
Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时） 架构。
具体细节可以详阅《Multi-Runtime Microservices Architecture》和《Mecha：将 Mesh 进行到底》。
哪些项目实现了 Multi-Runtime 架构？
Dapr
Dapr 的全称是“Distributed Application Runtime”，即“分布式应用运行时”，是一个由微软发起的开源项目。
Dapr 项目是业界第一个 Multi-Runtime 实践项目，Dapr 的 Sidecar，除了可以和 Service Mesh 一样支持服务间通讯，还可以支持更多的功能，如 state （状态管理） 、pub-sub （消息通讯） ，resource binding （资源绑定，包括输入和输出）
。Dapr 将每种功能抽象出标准化的 API （如 state API） ，每个 API 都有多种实现，比如用户可以面向 state API 编程，但是可以随意切换存储组件，今年用 Redis，明年改成用 MongoDB，业务代码不用改。
如果之前没有接触过 Dapr，更详细的介绍可以阅读《Dapr v1.0 展望：从 Service Mesh 到云原生》这篇文章。
Layotto
Layotto 是由蚂蚁集团 2021 年开源的一个实现 Multi-Runtime 架构的项目，核心思想是在 Service Mesh 的数据面 （MOSN） 里支持 Dapr API 和 WebAssembly 运行时，实现一个 Sidecar 同时作为 Service Mesh 数据面、多运行时 Runtime、FaaS
运行时。项目地址为：github.com/mosn/layott…
以上是本文背景，接下来是本次主题分享。
PART. 2 你真的需要这种“可移植性”吗？
社区比较关注 Dapr API 的“可移植性”，但在落地过程中，我们不禁反思：你真的需要这种“可移植性”吗？
标准化 API 能满足所有需求吗？
数据库领域曾出现过一个有趣的讨论：同一个数据库能否适用于所有场景，满足所有需求？ 比如，一个数据库能否同时支持 OLAP+OLTP+ACID 等等需求？
今天，我们在建设 Dapr API 的过程中也遇到了有趣的问题：在某个产品领域 （比如消息队列） ，能否定义一套“标准 API”同时适用于所有的消息队列？
当然，这两个问题不能混为一谈：即使是两种不同类型的数据库，比如两个数据库，一个只做 OLAP，另一个只做 OLTP，它们都可以支持 SQL 协议。两个差距那么大的数据库都能用同样的协议，我们有理由相信：在特定领域，设计一个适用于所有产品的“标准 API”是可行的。
可行，但现在还不完全行。
现在的 Dapr API 还比较简单，简单场景足以胜任，但在复杂的业务场景下，做不到“帮助应用 Write once,run on any cloud”。对这个问题，敖小剑老师的文章《死生之地不可不察：论 API 标准化对 Dapr 的重要性》有过详细描述，大意是说：
现在的 Dapr API 比较简单，在生产落地的时候满足不了复杂需求，于是开发者只能添加很多自定义的扩展字段，在 Sidecar 的组件里做特殊处理。比如下面是用 State API 时候的一些自定义扩展字段：
（图片摘自敖小剑老师的文章）
这些自定义的扩展字段会破坏可移植性：如果你换一个组件，新组件肯定不认识这些字段，所以你得改代码。
之所以出现这个问题，背后的根本原因是 Dapr API 的设计哲学。
社区在设计 Dapr API 时，为了可移植性，设计出的 API 倾向于 “功能交集” 。比如在设计 Configuration API 时，会考察各种配置中心 A、B、C，如果 A、B、C 都有同一个功能，那么这个功能才会出现在 Dapr API 中：
然而，在现实世界中，人们的需求可能是 A 和 B 的交集，B 和 C 的交集 （如下图红色部分） ，而不是 A、B、C 的交集：
或者更常见，用户的需求是“B 的所有功能”，其中必然包括一些 B 独有的功能，Dapr API 无法覆盖：
Dapr 提供“标准 API”、“语言 SDK”和“Runtime”，需要应用进行适配 （这意味着老应用需要进行改造） ，侵入性比较大。
因此 Dapr 更适合新应用开发 （所谓 Green Field） ，对于现有的老应用 （所谓 Brown Field） 则需要付出较高的改造代价。但在付出这些代价之后，Dapr 就可以提供跨云跨平台的可移植性，这是 Dapr 的核心价值之一。
这些听起来是解决不了的问题。那怎么办？
跨云部署时，你真的需要从 Redis
换成 Memcached 吗？
在设计 API 时，常常出现类似的讨论：
A：嘿，这个功能只有 Redis 和 xxx 有，但是 Memcached 和其他存储系统没有。我们该怎么办，要不要把这个功能纳入 API 规范里？
B：如果我们把这个功能纳入 API 里，会有什么问题？
A：那样的话，使用我们 API 的用户就没法从 Redis 迁移到 Memcached 了，这破坏了可移植性！
等一等……你真的需要从 Redis 换成 Memcached 吗？
你真的需要这种“可移植性”吗？
不需要吧！如果你的应用是面向 Redis 编程的，那它天生就能部署到不同的云上，因为每个云环境都有托管 Redis 服务。如果没有这种服务，你可以自己部署一个 Redis，让它有。
而且不止是 Redis，其他开源产品也可以类似操作。
舔狗定理 .
曾经听过一个很有意思的观点 （不是我说的） ：商业公司们就像舔狗，哪个开源产品有商业机会，商业公司很快就会去跟进，那个产品就会在各种云上出现托管服务。话虽糙，但揭示了一个道理：开源产品的协议天生具有可移植性。
标准化 API 的价值是限制私有协议
为了让讨论更具体，让我们把应用依赖的基础设施协议划分成两类：可信协议与私有协议。
可信协议
指在某个领域影响力比较大的协议，衡量标准是：有托管服务的云环境 >=k （k 是某个让你有安全感的数字，比如 3，5）
比如 Redis 的协议，基本可以认为是和 SQL 一样的事实标准了，各个云厂商都提供了 Redis 托管服务；再比如 MySQL 协议，各个云厂商都会提供兼容 MySQL 协议的数据库托管服务。
观点 1： 可信协议天生具有可移植性。
没必要担心“万一我以后想换云部署时，没法从 Redis 切换到 Memcached 怎么办”。因为每个云上都有兼容 Redis 的托管服务。
担心要从 Redis 换成别的缓存产品，就像是担心“假如我今天引入了 Sidecar，如果以后 Sidecar 架构不流行了，我要去掉 Sidecar 怎么办”，或者“假如我今天引入了 Spring Cloud，以后其他框架火了，我要换成别的框架怎么办”。那一天当然会出现，但是大部分业务都活不到那一天，如果能，恭喜你，到那时你会有足够的资源做重构。
私有协议
比如闭源产品的协议，或者影响力小的开源产品的协议，衡量标准是：有托管服务的云环境<k。
举个例子，蚂蚁内部的 MQ 是自建 MQ，使用私有协议，业务代码依赖了这种私有协议就不好部署到别的云环境了，所以适合用标准化 API 包一层。
再比如，你在调研接入某个阿里云提供的 MQ，但是发现这个 MQ 的 API 是阿里云独有的，别的云厂商不提供这种服务，如果你害怕被阿里云绑定，最好用标准化 API 把这个私有 MQ API 包一层。
读到这，你应该明白我想说的了：
观点 2：
Dapr 标准化 API 的价值是限制私有协议。
题外话 Sky Computing，2021 年，UC Berkeley 发了篇论文，预言云计算的未来是 Sky
Computing，大意是说：回看互联网的历史，互联网连接了各种异构网络，对用户暴露出一个统一的网络，用户面向这个网络编程不需要关心具体每个异构网络的细节；今天不同云厂商的环境有差异，像极了互联网出现之前“各立山头”的状态，为了让用户更方便，我们可以设计一个“互联云”，连接各种异构云环境，屏蔽差异，只对用户暴露统一的抽象。连接不同云，可以叫“空计算”。
那怎么实现呢？
作者提出了 3 层概念模型，最基础的第一层是“兼容层”，负责抽象不同云服务，让应用能够不改代码部署在不同云上。作者认为，开源软件在各个云上都有托管服务，所以可以把不同开源软件整合成一个平台，形成“兼容层”，并且现在已经有项目在这么做了，比如 Cloud Foundry。
在“兼容层”之上，作者认为应该还有“Intercloud 层”和“Peering 层”，感兴趣的可以阅读原文。
我们需要什么样的“可移植性”
题外话，计算机科学中有一种思想：如果一个问题太难了解决不了，那就放宽假设，弱化需求。用大白话讲就是：如果一个问题太难了解决不了，那就先解决一些更简单的问题。这样的例子很多，比如实现数据库事务的“隔离性”会导致性能很差，只能在实验室环境使用，无法用在现实世界，于是人们提出“弱隔离性”，罗列出“读提交”，“可重复读”之类的“弱隔离级别”，越弱的问题越好解决。
比如在现实世界中，求解 NP-Hard 问题的最优解太慢了，不可行，于是人们提出，放弃追求最优解，只要能保证算法给出的结果在“可以承受的范围内”就行，于是有了“近似算法”；如果这也太难了，那就用玄学算法——“启发式算法”；
比如想实现“对业务透明”的分布式事务比较难，要付出很多代价，于是人们就提出放弃“对业务透明”，于是就有了 TCC 和 Saga；……
既然“可移植性”这个问题太难了，那就让我们弱化一下需求，先解决一些更简单的问题：“弱移植性”。
可移植性分级
“可移植性”这个需求太模糊了，我们先明确下需求。我们可以把可移植性分成多个等级：
level 0：业务系统换云平台部署时，需要改业务代码 （比如换一套基础设施 SDK， 然后重构业务代码） 。
这是常见状态，比如某公司内部有一套自研消息队列系统“XX MQ”，有一个“xx-mq-java-sdk”供业务系统引入。当业务系统想要上云 / 换云部署时，由于云上没有“XX MQ”，需要换一个 MQ （比如换成 RocketMQ） ，业务系统需要做重构。
level 1：换云平台部署时，业务代码不用改，但是需要换一套 SDK，重新编译。
社区有一些通过 SDK 做跨平台的方案，属于这个级别。比如携程开源的 Capa 项目，比如腾讯开源的 Femas 项目。
level 2：换云平台部署时，业务系统不需要改代码，不需要重新编译，但是 Sidecar 要改代码。
level 3： 换云平台部署时，业务系统和 Sidecar 都不需要改代码，不需要重新编译，只需要改配置。
level 4： 换依赖的开源产品时 （比如原先使用 Redis，现在要换成别的分布式缓存） ，业务系统和 Sidecar 都不需要改代码。
社区的最终目标是 level 4，但是上文已述，现在还没法完美实现，存在种种问题。对于需要快速落地，解决业务问题的商业公司，现在能实现的目标是：追求 level 2 的可移植性，部分场景可以达到 level 3，这就足够解决业务问题了。
比如分布式缓存场景，蚂蚁在 MOSN 里自建了一套分布式缓存中间件支持 Redis 协议访问，如果你相信 Redis 协议是具有可移植性的，那么应用通过 Redis 协议和 MOSN 通信即可，没必要强行迁移到 Dapr 的“State API”上。在这种情况下，标准化 API 只是作为补充。
题外话，Sky Computing 的“兼容层”需要哪种可移植性？ 按照这种分级方式，Sky Computing 提出的“兼容层”需要 level 3 及以上的可移植性。
如何实现 level 3 可移植？
如果我们把目标定为 level 3，那么 Runtime 对外暴露的“兼容层”协议应该是多种多样的，包括各种领域的可信协议 （比如 Redis 协议、MySQL 协议、AWS S3 协议等） ，以及 Dapr 风格的标准化 API。
由此，我们可以得出两个观点：
观点 3：
拥抱可信协议：Dapr 标准化 API 的定位应该是作为可信协议的补充，而不是试图让用户放弃可信协议，迁移到 Dapr API 上。
观点 4：
设计 Dapr 标准化 API 时，要专注于那些还没有形成可信协议的领域，为这些领域设计标准化 API，而不是花精力设计“Another SQL”，或者纠结“如何从 Redis 迁移到 Memcached”。比如，不同云厂商的配置中心提高的 API 不一样，还没形成事实标准，那么设计一套跨平台的 Configuration API 就能填补这个空缺。
演进路线
现在我们回答最开始提出的问题：现在的 Dapr API 有很多问题，比如自定义扩展字段太多，破坏可移植性，比如面向“交集”做设计，功能太弱难以演进，比如侵入性强等等，该怎么办？
答案是：逐渐演进，先考虑从 level 2 演进到 level 3。
为了实现 level 3，我们需要：放弃面向“功能交集”的设计，改为面向“功能并集”做设计；在 Sidecar 直接支持各种“可信协议”。
而为了实现最终的 level 4，我们需要：标准化 API 是完备的“功能并集”，保证覆盖到所有的业务场景；有一套“feature 发现机制”，应用在部署时和基础设施协商“我需要哪些 feature”，基础设施根据应用的需求自动绑定组件。
PART. 3 Runtime 架构带来的价值
除了标准化 API，实践中 Runtime 架构更大的价值在于以下几个方面：
一、可能是最重要的价值：让“下沉”合理化
一个有趣的观察是：以前 Mesh 的概念强调“代理”，因此一些基础设施产品想把自己的代码逻辑也“下沉”进 Sidecar 时可能会遭到 Mesh 团队的拒绝，或者能“下沉”进去，但是实现的比较 hack，并不规范；而有了 Runtime 的概念后，各种产品把代码逻辑挪到 Sidecar 行为就合理化了。
这里说的“下沉”，是指“把应用依赖的公共组件从应用里挪到 Sidecar 里”，分离核心业务逻辑和技术部分。好处就太多了，比如：
1.多语言复用中间件
Service Mesh 宣传的好处之一是让多语言应用复用流量治理类的中间件，现在 Runtime 强调把更多的中间件放进 Sidecar，意味着有更多的中间件能够被多语言应用复用。比如，以前的中间件都是为 Java 开发的，C++ 用不了，现在可以让 Node.js/Python/C++ 语言的应用通过 gRPC 调 Sidecar，复用中间件。
2.微服务启动加速、FaaS 冷启加速
原先微服务应用的框架比较重，比如有和配置中心建连、初始化、缓存预热之类的逻辑，现在这些启动逻辑都挪到 Runtime 里。当应用或者函数需要扩容时，可以复用原有 Runtime，不需要再做一遍类似的建连预热动作，从而达到启动加速的效果。
3.不用推动用户升级 SDK 了
这个就是 Mesh 一直讲的好处：有了 Sidecar 后，不需要天天催促各个业务方升级 SDK，提高了基础设施的迭代效率。
4.让业务逻辑也能下沉
除了基础设施，一些业务逻辑也有放进 Sidecar 的诉求，例如处理用户信息等逻辑。
让业务逻辑放进 Sidecar 需要保证隔离性，去年尝试了用 WebAssembly 来做，但是不太成熟，不敢在生产中使用，今年会尝试其他方案。
二、让“下沉”规范化：约束“私有协议”，保证能实现 level 2 可移植
在“下沉”的过程中，标准化 API 更多起到约束“私有协议”的作用，比如：
- 限制私有协议的通信模型
设计私有协议时 （Layotto 支持“API 插件”功能，允许扩展私有的 gRPC API） ，需要证明“这个私有协议在其他云上部署时，存在一个能切换的组件”
- 作为设计私有协议的指导
参照着标准化 API 去设计私有协议，有理由相信设计出来的协议在换云部署时，能达到 level 2 可移植性
三、RPC 协议转换、微服务互通
Dapr 的 InvokeService （用来做 RPC 调用的 API） 设计的比较简单，也有一些不足，在实际 RPC 场景中，Layotto 调整了它的定位，作为 Service Mesh 的辅助：
已有的 Java 微服务的 RPC 流量还是通过 Service Mesh （MOSN） 进行转发，而对于其他语言的微服务，或者其他协议栈的微服务，可以通过 gRPC 调用 Sidecar，由 Sidecar 帮忙做协议转换，然后把流量接入已有服务体系。
比如很多语言没有 Hessian 库，可以通过 gRPC 调 Layotto，Layotto 帮忙做 Hessian 序列化，然后将流量接入 MOSN。
业界也有一些做多语言微服务打通的项目，比如 dubbogo-pixiu 项目，区别是通过网关的形式部署。
PART. 4
如何划分 Serivce Mesh、Event Mesh 和 Multi-Runtime 的边界？Serivce Mesh 和 Event Mesh 的区别是什么？
网上的说法是 Event Mesh 处理异步调用的流量，Service Mesh 处理同步调用。
Service Mesh 和 Dapr 的区别是什么？网上的说法是 Service Mesh 是代理，Dapr 是运行时，要抽象 API，做协议转换。
但是，随着落地演进，我们渐渐发现这些技术概念的边界变得很模糊。
如下图，Layotto 这个 Sidecar 支持了各种协议，好像已经“非驴非马”了：不只是 Dapr 式的对外暴露标准化 http/gRPC API，抽象分布式能力，也包括 Service Mesh 式的流量拦截、代理转发，能处理同步调用、异步调用，能处理 Redis 等开源协议的请求，好像把 Event Mesh 的事情也做了，已经变成了一种混合模式的
Sidecar：
所以，如何划分 Serivce Mesh，Event Mesh 和 Multi-Runtime 的边界？
个人观点是，可以把 Dapr 的“标准化 API”看做“Sidecar 增强” 。比如“InvokeService API”可以看成“Service Mesh 增强”，“Pubsub API”可以看成是“Event Mesh 增强”，“State API”可以看成“数据中间件增强”，这里说的数据中间件包括缓存流量转发和
DB Mesh。
从这种角度看，Layotto 更像是 Sidecar 里的“API 网关”。
PART. 5 部署形态之争
一、目前的架构有什么问题？
目前的架构存在一个问题：Runtime 是个巨石应用。
不管是 Dapr 还是 Layotto，都倾向于承载所有和业务无关的功能。
如果你把 Runtime 类比成操作系统的内核，那么 API 这层就是系统调用，负责抽象基础设施，简化编程，而不同的组件类似于驱动，负责把系统调用翻译成不同基础设施的协议。
Runtime 把所有组件都放在一个进程里，类似于“宏内核”的操作系统把所有子模块都塞在一起，变成了巨石应用。
巨石应用有什么问题？模块间互相耦合，隔离性不好，稳定性降低。比如之前就有研究指出 Linux 中大部分的代码是驱动，而且很多驱动是“业余玩家”写的，稳定性不好，驱动写的有问题是 kernel 崩溃的主要原因。
同样的，如果 Dapr 或者 Layotto 的一个组件出现 bug，会影响整个 Sidecar。
怎么解决巨石应用的问题呢？拆！一个思路是把 Runtime 按模块拆分，每个模块是一个 Container，整个 Runtime 以 DaemonSet 的形式部署：
这种方案就像操作系统的“微内核”，不同子模块之间有一定的隔离性，但相互通信的性能损耗会高一些。比如 Event Mesh 容器想要读取配置中心的配置时，就需要通过网络调用 Configuration 容器；如果调用频率过高，就要考虑在 Event Mesh 容器里做一些配置缓存，可能最后每个容器都要做一套缓存。
那么应该选择单容器 Runtime 还是多容器 Runtime 呢？这就像操作系统选择“宏内核”还是“微内核”架构，全看取舍。巨石应用的好处是子模块之间互相通信性能好，缺点是紧耦合，隔离性不好；如果把 Runtime 拆成多个 Sidecar 则刚好相反。
目前，Dapr 和 Layotto 都是单容器 Runtime。
一个可能的拆分方案是：将 Runtime 按能力“垂直拆分”成多个容器，比如一个容器负责状态存储，一个容器负责异步通信等等，容器间通信通过 eBPF 做优化。不过目前还没看到这样做的项目。
二、目前的架构还可以做哪些优化？
优化点 1：启动应用时，需要先启动 Sidecar 容器，再启动应用容器。能否让应用启动加速？
直觉上想，如果能让新启动的应用 （或函数） 复用已有的 Runtime，就能省掉一些初始化动作，加速启动。
优化点 2：能否减少 Runtime 的资源占用？
每个 Pod 都有一个 Sidecar 容器，假如一个节点有 20 个 Pod，就得有 20 个 Sidecar，在大规模集群里光是 Sidecar 就要占用很多内存。
能否减少 Runtime 的资源占用？
直觉上想，如果能让多个容器共享同一个代理 （而不是每个容器独享一个代理） ，就能减少资源占用。
上述两点看起来都可以通过“让多个容器共享同一个代理”来做优化。但事情真有那么简单吗？
Service Mesh 社区关于“共享代理”的讨论
其实 Service Mesh 社区有过很多关于数据面部署形态的争论，大致有以下几种方案：
Sidecar 模式，每个应用独享一个代理
图片来自 <eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>
节点上所有 Pod 共享同一个代理
图片来自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>
不需要代理进程，用 eBPF 处理流量
很优雅，但功能有限，满足不了所有需求。
节点上每个 Service Account 共享一个代理
图片来自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>
混合模式：轻量 Sidecar+ 远端代理
图片来自<eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay>
Runtime 社区还需要共享代理吗？
上面几种方案看起来都行，只是取舍问题，但是到了 Runtime 这里，情况就变了！
情况 1：集群里有各种各样的中间件，各种各样的基础设施
如果集群里有各种各样的中间件，各种各样的基础设施，那还是别用“节点上所有 Pod 共享同一个代理”的模型了。
举个例子，某集群里有各种各样的 MQ，如果节点上所有 Pod 共享同一个 Runtime，Runtime 事先不知道 Pod 会用什么 MQ，所以它必须在编译时带上所有 MQ 组件。每次新建一个 Pod 时，这个 Pod 要动态把配置传给 Runtime，告诉 Runtime 它要用哪个 MQ，然后 Runtime 再根据配置去和相应的 MQ 建立连接。
比如下图，某个节点上，Pod 1、Pod 2、Pod 3 分别使用 RocketMQ、Kafka、ActiveMQ，这时新启动了一个 Pod 4，Pod 4 告诉 Runtime 它很有个性，它要用 Pulsar！于是 Runtime 就得去和 Pulsar 建连，做一些初始化动作。所以，Pod 4 启动并没有“加速”，因为它没能复用之前已有的连接。
这种情况下，共享 Runtime 并不能帮助应用启动加速，无法复用和后端服务器的连接数，虽然能省一些内存，但带来了一些缺点：增加了复杂度，降低了隔离性等等。
如果强行把 Sidecar 模型的 Runtime 改成共享代理，有用，但投入产出比不高。
情况 2：集群里基础设施的技术栈比较统一
在这种情况下，共享代理模型可能有一定价值。
比如，某集群只用一种 MQ，RocketMQ。假如使用共享代理模型，某个节点上 Pod 1、Pod 2、Pod 3 已启动，这时新启动一个 Pod 4 也要用 RocketMQ，此时就可以复用已有的一些元数据，甚至有可能复用和 MQ 服务器的连接。
这种情况下，共享代理模型的好处有：应用启动加速，复用和后端服务器的连接。
不过，所谓“启动加速”也是要看情况的，比如通过优化让 Runtime 启动快了 2 秒，但是应用启动却要 2 分钟，那么优化 2 秒其实并没有多大用处。尤其是有很多 Java 应用的集群，大部分 Java 应用启动不快，这点优化价值有限。所以，启动加速在 FaaS
场景会比较有用。如果函数本身启动、加载速度较快，优化几秒还是很有价值的。提高资源利用率，不用部署那么多 Sidecar 了。
PART. 6 总结
本文讨论了 Layotto 落地之后，关于 Multi-Runtime 架构“可移植性”、落地价值以及部署形态等方面的思考。且本文的讨论不限定于某个具体项目。
【参考链接】
《Multi-Runtime Microservices Architecture》：www.infoq.com/articles/mu…
《Mecha：将 Mesh 进行到底》：https://mp.weixin.qq.com/s/sLnfZoVimiieCbhtYMMi1A
《从 Service Mesh 到云原生》：https://mp.weixin.qq.com/s/KSln4MPWQHICIDeHiY-nWg
Dapr 项目地址：github.com/dapr/dapr
Layotto 项目地址：github.com/mosn/layott…
Capa 项目地址：github.com/capa-cloud/…
Femas 项目地址：github.com/polarismesh…
【本周推荐阅读】
蚂蚁集团 Service Mesh 进展回顾与展望
应用运行时 Layotto 进入CNCF 云原生全景图
云原生运行时的下一个五年
MOSN 文档使用指南