仅凭几个前端工程师，就能 hold 住一家企业吗？

出主要是通过 OpenAPI，用以集成到企业自己的业务场景中，这里主要解决的还是企业底层的能力问题——无需雇佣算法工程师，就可以拥有语音、图像识别等能力。安全也是一样，不需要找安全专家，普通的工程师就可以通过控制台高效地处理各种安全事件。

但是，随着云技术不断的下沉，与产业结合的越来越紧密，OpenAPI 唯有把粒度做得越来越细，才能满足各种各样的业务场景，但同时企业侧的学习成本和开发复杂度自然就上去了。控制台做为管(理)控(制)这些能力的工具，目前也只能算是「标品」，必须为了满足不同体量、不同业务特点的需求，灵活地组合和部署，就像是用户自己开发的一样。

综上所述，微前端的价值有 3 点：

1. 解决产品侧的扩展性和组合性。化整为零，自由组合。
2. 解决能力输出的「最后一公里」。
3. 云生态中的「新物种」 — 微应用。

如果微前端只存在工程上的价值，那它是不值得大张旗鼓去做的。

我认为，前端团队需要在这个方面做出业务价值。如果你问我 Ant Design 有什么技术价值?它的价值就是有大量的企业在用，形成某种能力依赖，不需要找设计师或者多么资深的前端工程师，就可以做出看上去很专业的后台界面。

在这条价值链路上，OpenAPI 太底层，控制台不灵活，UI 库太通用。其中的空白点是绑定能力的商业化组件。举个例子，企业的后台管理页上，可以直接 inside 一个「漏洞管理」的微前端应用，和一个 DataV 的微前端应用展示数据，只需要简单配一下即可，不用开发，就能做到“就像自己开发的一样”。反过来也一样，ISV 在阿里云的产品平台上，不仅可以通过小程序的形式，也可以通过微前端应用的形式输入自己的服务。

微前端的问题域

简单地说，搞微前端目的就是要将产品原子化(跟原子化的 OpenAPI 一个道理)，再根据客户业务场景组合。每个功能模块能单独迭代，自由集成当然好，但维护成本怎么控制。怎么调试、公共组件版本控制、众多同窗微应用之间怎么“和谐相处”等等。微前端并非只是解决在页面上异步加载一个模块就完事了，更多的是将改造引发的一系列问题需要通过体系化的方案解决，否则就变成反生产力工具。

（编辑：阜阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!