天猫网站内容架构分析(一个简单的扩展点示例：由业务方进行接口声明)

　　天猫网站内容架构分析(一个简单的扩展点示例：由业务方进行接口声明)

　　扩展点的基础是基于接口的服务协议。扩展点不限制接口声明的主体。可以是业务方，也可以是微服务开发方式，运营平台提供接口声明。一个简单的扩展点接口示例：

　　@ExtensionPointerpublic interface ActiveUserService {boolean contains(long activeId, long uid);void remind(long activeId, long uid);}

　　业务方做接口声明的好处是贴近接口用户，避免不必要的参数转换；也达到了依赖倒置的目的，业务方可以独立接入运营平台，无需预先投入运营资源。

　　接口声明完成后，会在启动时通过maven插件扫描、代码扫描、sdk扫描自动上报到扩展点后台，供操作平台后续开发使用；对于接口的声明者，会自动有一个空格。它调用的接口实现。

　　开发环境设置

　　实现业务端和运营平台的完全解耦，需要解决扩展点实现时的开发环境搭建问题。如果业务方只需要声明接口并提供接口jar，那么运营平台将基于接口jar构建开发环境。与以往的合作模式相比，本质上没有任何改变。

　　业务端声明接口，提供接口jar，会带来jar依赖泛滥的问题。很可能一个接口只用到了四个类，但是接口jar引入了50个依赖jar。这些额外的 jars 是在应用程序启动时引入的。这将是一个额外的负担；此外，为了保密，企业有时不会将自己的 jar 部署到公共图书馆。当业务端提供jar时，需要对原有的jar进行拆分，需要额外的工作量。

　　有没有办法尽量减少对业务方开发人员的干扰，自动完成开发环境搭建？扩展点仔细考虑了这些问题，目前通过mock类形成开发环境：

　　模拟类

　　类的mock并不复杂，有很多方法：

　　接口实现——能力

　　扩展点接口的实现类称为能力。示例代码如下：

　　public class ActiveUserServiceAbility implements ActiveUserService {@Overridepublic boolean contains(long activeId, long uid) {return true; }@Overridepublic void remind(long activeId, long uid) {}}

　　界面变化

　　随着业务的发展，肯定会有我们需要对界面进行调整，在旧界面中添加方法的一天。扩展点兼容这种情况（需要jdk8)，方便大家开发：

　　@ExtensionPointerpublic interface UserService {default String getName(long uid) {return null; }}

　　@ExtensionPointerpublic interface UserService {String getName(long uid);}//增强前public class UserServiceAbility extends UserService {}//装饰接口public interface __AE_Decorator_UserService extends UserService {default String getName(long uid) {return null; }}//增强后public class UserServiceAbility extends UserService implements __AE_Decorator_UserService {}

　　配合接口变更的兼容处理机制，业务方可以增量调整接口，扩展点后台会根据业务方的调整自动维护最新的开发环境。另一方面，运营平台不必担心业务端的调整会导致原创代码无法编译运行。

　　本地化部署

　　开发环境一路搭建顺利，代码喝完咖啡，接下来就是部署了。

　　微服务架构下，运维平台将项目打包成一个大的fat jar，然后部署到镜像容器中。当业务方调用时，会发起远程RPC请求。为满足流量漏斗、RT精准控制、运营配置无损获取等需求，扩展点提出了本地化执行的目标。

　　扩展点在本地执行时，代码有序地通过CPU流水线，执行状态存储在L1、L2缓存、寄存器和内存中，均以纳秒和微秒为单位；分布式部署，一切都上升到毫秒级。本地化执行的优势很明显：速度快。

　　本地化执行自然需要本地化部署。将扩展点部署到调用者的 JVM，有以下三种模式：

　　运行时部署对业务侧没有额外要求，扩展点采用这种模式。大致流程如下：

　　jvm多租户隔离

　　本地化部署会导致本地计算资源被占用。例如，一段计算密集型代码，一个无限循环。

　　//造成业务失败的代码while(true){//code }

　　业务方需要一些机制来防止扩展点过度消耗自身的计算资源。在java界，jvm多租户隔离可以解决这个问题，java中的JSR121、JSR284、JSR342等规范都对多租户系统进行了探索。目前阿里的ajdk已经提供了多租户管控能力，可以为每个租户独立分配CPU和内存。

　　部署时，我们可以将扩展点部署在单独的 jvm 租户上。租户的CPU和内存受到严格限制，以免干扰业务方本身的执行。

　　本地化风险

　　扩展点的本地部署本质上是代码注入，会带来安全隐患。目前已知的风险有：

　　原子应用程序拆分

　　我们解决了开发环境的问题，也有一套基本的部署机制。我们很开心。现在我们可以按照扩展点的模式进行业务开发。

　　随着越来越多的扩展点被写出来，我们又遇到了新的麻烦。每个扩展点都需要一个独立的项目作为基本部署单元。扩展点越多，IDE 中的项目就越多。当微服务如此简单的时候，为什么现在有这么多？如果我们在一个项目中提供三个扩展点可以吗？部署时要做什么？

　　之前搭建开发环境的时候，我们采用了递归扫描类依赖，逐个mock的方案。是否可以执行基于依赖扫描的应用程序自动拆分部署？仔细想想，似乎可行。当我们完成开发并提交代码后，扩展点框架会自动扫描项目项目（如提供maven插件），采集扩展点实现类的依赖关系，并根据应用将应用划分为几个独立的原子应用依赖项。收录一个扩展点。

　　此外，我们可以扫描和拆分任何 java 项目并将其分解为独立的原子应用程序。借助这些独立的原子应用程序，可以以最小的粒度部署扩展点。

　　通过应用拆分，可以以最自然的方式组织项目，让程序员可以在扩展点的天空中自由翱翔。

　　状态分裂

　　在拆分原子应用程序时，需要重点关注一些基本配置，包括dockfile、属性和应用程序启动时的初始化对象。

　　集装箱化

　　到目前为止，我们的扩展点只是一个代码注入框架，我们可以更进一步，吸收微服务的分布式能力，将扩展点容器化。

　　想象一下，系统中有几个本地化的扩展点。当达到系统容量上限时，将某个扩展点拆分为远程微服务。每时每刻，系统都会根据当前热点自动调度和调整扩展点的部署。扩展点有时是本地的，有时是远程的。调用者不关心扩展点在哪里，提供者也不关心扩展点部署在哪里。整个扩展点的部署按需分配。

　　无服务器

　　在 serverless 架构下，开发不再需要关心具体的部署，扩展点自然是 serverless 架构。

　　运维平台开发完成后，原子应用拆分后，系统获取扩展点部署的所有信息，然后将代码发送给业务端应用进行部署。整个过程中，运营平台只需要提供代码，不提供服务器本身。

　　因为扩展点已经被拆分成原子粒度的应用程序，每个应用程序都可以独立部署，只要放宽扩展点本地化部署的约束，引入一定的容器技术，扩展点就具有无服务器能力；应用程序粒度的弹性伸缩和扩展点粒度的弹性伸缩可以实现更快的部署和更少的资源消耗。

　　目前阿里巴巴的 serverless 框架有很多，我们可以选择一个来集成。

　　合并部署

　　可以预见，一些qps低的长尾扩展点可以合并部署。有两种类型的合并部署。最简单的是一个JVM启动多个应用程序。此外，需要尝试多个扩展点以合并到一个应用程序中进行部署。

　　合并的难点在于冲突jar的处理和同名配置项的处理。合并没有公共依赖类的扩展点是最容易的；如果有公共依赖类的扩展点，需要处理jar冲突。

　　大多数常见的依赖项是各种通用框架的消息、缓存、日志和jar。可以借鉴阿里巴巴潘多拉容器的思想：容器统一控制类的加载，所有扩展点都优先使用容器提供的类。

　　通过合并部署，我们可以将几个相关的扩展点部署在一起，更好地控制RT和资源利用率。

　　代码互联与超级jvm

　　沿着扩展点的思路继续思考：当拆分级别细化到类的方法时会发生什么？

　　每次提交代码，分析其结构，拆分每个独立的原子方法；然后对每个独立的原子方法进行归一化计算，等价的原子方法自动合并替换。这些处理后的原子方法都可以服务化，可以统一部署、伸缩、调度和监控。

　　在这样的过程中，代码先结构化，再代码互联，服务按需组装，最后进行动态调度，可以将代码的复用水平提升到极致。这样的 jvm 将是一个超级 jvm，它集成了跨编译、部署和执行环节的所有 jvm。

　　上面的想法，一家人的话，博君笑了笑。

　　写在最后

　　从一个想法到实现扩展点，各种事情都已成为过去；目前，扩展点也在大力支持运营平台的发展；与遥远的星海相比，未来还有更远的路。

　　有一天，我们只需要编写业务代码。

　　有一天，我们将使用人工智能来找出代码。

　　AI Labs 程序员的梦想。

　　附录

　　（超过）

　　其他选择文章：

　　天猫精灵对话引擎如何设计网关？天猫精灵的架构供您参考

　　天猫精灵的边缘异构计算引擎ACE

　　来自天猫精灵的 AutoML