天马网络 网站建设 第1篇
一个模块发布后，会同时同步到 CDN 和 npm 上，CDN 版本给到纯浏览器和服务端使用，tnpm 部分给到小程序和源码页面等其他有页面级构建能力的场景使用。
目前淘系选择了 Rax 作为统一 DSL，基于上面的搭建设计，加上 Rax 本身一次开发多端运行的能力，就可以实现我只需要写一份无线端 web 的代码，分别转出 weex、小程序的版本，这样我的模块投放到 webview 里就是 web 模式，投放到小程序里就是原生小程序，投放到 weex 就可以以 weex 形式渲染。
社区方案的差异
由于解决问题的特殊性，这套方案和社区也有出现一些差异。 简单说只是在社区的基础上，加了一些约定和文件，在依赖分析和处理上虽然有差异，但实际上背后的思路是相通的。
天马网络 网站建设 第2篇
从非技术同学作为搭建主要用户的角度来思考，以及无线化场景下，手机屏幕的特征，一维存储的模块列表是比较友好的。这个设计也对搭建服务本身带来了很大的简化，整个页面结构就是一维数组，每次操作都可以转变成一次简单的数组操作。当然，一维的存储不代表一维的展示，开发者依然可以在展示的时候，通过一些父子关系，来把一维的存储结构转变为树状结构。目前我们是判断把复杂度给开发者，简单的设计给到非技术同学，还是一个比较合适的方式。并且一维的页面结构也可以更好地融合后端的数据，无论是搭建的智能化自动化还是面向端侧的个性化，都可以结合的更好
搭建结果可以跨终端访问也是和阿里的一些业务特征有关，因为无线化的战略，至少在消费者端，公司在无线上的投入比桌面端大很多（主要是消费者侧），那么如果能搭建无线页面，然后桌面端自动生成，或者反一下，对搭建用户来说可以省掉很多时间。特别是当下极端一些的场景，用户搭建一个无线端页面，需要同时额外生成 pc、weex、小程序的版本。当然，这个只是默认选项，搭建用户还是可以选择只搭无线，或者只搭桌面端，或者都搭但是不是自动同步。
天马网络 网站建设 第3篇
回到天马本身的话，核心设计了 3 个分层：
基础服务层：负责基础搭建数据的管理，比如模块、页面、用户、管理等模型的增删改查。这一层设计的足够通用，简单，不感知业务逻辑，也尽量少对外依赖，确保一个个功能单元足够颗粒化。
能力层：因为如果我们只提供一个基础服务层，就会遇到一个问题，上层搭建应用接入的时候非常复杂，处理用户的一个操作，背后可能需要调用到基础服务层的多个接口，这些操作组合还是比较容易出错的，所以在能力层对这些基础服务进行了组合，降低接入成本。另一方面，有了能力层，和大量外部系统的交互就可以在这里完成，比如和小程序后台、性能检测等平台对接。这一层的产物包括了 API 接口，搭建的脚手架，模块管理平台等等。
研发服务层：研发能力主要分为核心的构建器、提升模块研发体验的可视化研发插件、面向不同场景的初始化脚手架、以及配套的研发文档。文档也是重要功能，不管是面向开发者还是其他非技术用户。