主页

一.为什么要组件化架构升级 1.1 现状 玩吧 app 架构从一开始的”ALL IN ONE”模式，逐渐演变到现在的单 project 多 module 架构，目前架构图如下： 1.2 目前的发现的问题 依赖中心化，core 和 sdk 层都通过 common 层给 feature 层提供服务，api 引入组件的方式造成依赖不清晰，编译时间变长 公共服务中心化，feature 层的公共逻辑都在 common 中 模块对外暴露的服务不可知，都是直接依赖内部代码逻辑 core 层、sdk 层级界限不清晰，同层之间存在依赖 代码单仓库，模块无法单独打包，需要全量编译 1.3 架构调整的目标 架构调整核心目标是解耦和提高复用，去除代码中心化问题，解耦现有业...

前言 本文主要是从个人的经历出发，阐述从我自身的视角来理解的架构师工作职责与前进方向。本文没有具体的架构师成长演进路线，而是提供了一份自己在架构设计上的一些观察与思考，作为其他同学往架构设计方向发展的参考。本文的概念性内容较多，如果感觉理解起来较为困难，可以从扩展阅读中理解对应概念，再回过头来进行本文的阅读。另外本文虽然引用了一些辩证法等相关哲学思想，但是由于涉及到了个人具体实践和个人语言能力、符号表达能力、原理理解能力的限制，相关思想会有明显的概念坍缩，从而变的庸俗化，勿要严格对号入座。 什么是软件架构 软件架构（software architecture）在我的理解中，是指在软件系统当中，多个构件之间组织形式的抽象。根据解释语义，可以从中提取出主要概念：构件，组织形式，抽象。...

方案定义 本框架为后续跨平台以及容器化方向开发提供基础运行框架，建设基础核心组件，规定基础交互协议等方面的规范。 设计目标 本框架设计的主要目标为以下两点： 实现容器化后不同层级不同组件之间的跨语言功能调用； 构建容器组件的虚拟运行平台。 边界 跨语言交互框架范围为PB支持范围与语言FFI支持的交集。 容器组件为业务层容器组件。 本框架设计暂不包含跨进程消息传递。 架构设计 架构解释 整个技术架构为星型拓扑(Star Topology)，整体结构功能如下： 中央节点为星桥（Star Bridge），功能为多语言消息互传，通过跨语言FFI来实现。一般星型拓扑的瓶颈在于中央节点的负担过重，因此星桥内虽然具有不同平台的消息路由功能，但不包括路由表本身...

一 什么是事件驱动架构 Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. – – by Wikipedia 1.1 什么是事件 首先明确下，什么是事件：事件是已经发生的事实，并且不可变。就程序设计领域来说，是指系统硬件或软件的状态出现任何重大改变。 事件与事件通知不同，后者是指系统发送的消息或通知，用于告知系统的其他部分有相应的事件发生。而事件的来源可能是内部也可能是外部原因。事件可以来自用户（例如点击鼠标或按键）、外部源（例如传感器...

一、简介 编程语言对外展现出来的能力是语言 + 生态的一个合集。所以说一门编程语言的能力，语言本身的设计占了四成，围绕着语言打造的生态系统占了六成，生态可以弥补语言的劣势。 那么，Rust 的生态是什么样子呢? 我们可以用 Rust 做些什么事情呢? 为什么说 Rust 生 态系统已经不错，且潜力无穷、后劲很足呢? 主要从以下这几个方面进行介绍： 基础库 Web和Web开发 客户端开发（GUI） 云原生开发 WebAssembly开发 嵌入式开发 机器学习开发 音频处理 视频处理 图形图像 … 二、展开介绍 1、基础库 按照重要程度依次简单说一下，方便根据需要自行跳转: 序列化和反序列化工具 serde 网络和高...

平台能力容器 容器定义 容器是指无强制外部依赖与外部接口平台无关化。因此我们需要设计一套容器间的交互协议用于去除强制外部依赖，同时通过定义一套统一的调用接口来完成外部接口对平台端差异的屏蔽性。 容器模板设计 容器本身内部的业务能力还是由对应平台端来实现，但是由于除了业务能力自身，我们还需要对业务内容进行一些通用型的处理，如多语言支持，性能数据监控与管理，同时对未来上层业务的容器化支持提供扩展的可能性。因此我们需要定义一套模板来对其进行具体约束。 平台能力容器管理器 跨容器交互协议 基于类似 ALPC(Advanced/Asynchronous Local Procedure Call)规则，交互模式采用 C/S 机制，交互实体分为请求(Request)与响应(Respon...

为什么需要跨平台语言 目前业界常见的跨平台方案主要分为三种：桥接、进程间通信、canvas绘制。而这些解决方案着眼点都是如何用更少的代码能够做出高效统一接近原生的UI。 但这些方案都无法解决非UI层的业务逻辑代码如何安排的问题。如果用跟UI层一样的语言，则无法保证运行时效率；如果不用UI层的语言编写，而使用native层的语言，那带来的效率提升将极其有限，甚至反而造成更高的复杂度。事实上，大量的业务逻辑用JS/Dart这样的语言并不合适，随着业务迭代，往往到最后还是iOS写一部分、Android写一部分，然后使用桥接器做接口。 除此之外，这些方案还都忽略了一个重要的问题：如今 app 变得越来越复杂，复杂的不仅仅是 UI，还有业务逻辑。业务逻辑支撑着 UI，如何在所有平台上尽可能...

背景与目标 平台化是大前端在 22 年的主要技术建设目标，结合目前大前端的技术栈与发展情况，我们制定了如下目标： 实现大前端通用业务逻辑下沉，解除大前端基础组件和通用业务对公司业务的耦合 构建以平台化为核心的业务容器平台，并实现快速集成复用方案，至少实现基础组件与核心业务能力的可复用性 建立全链路的业务性能监控体系，大幅度提高线上问题预警能力、发现能力、定位能力，提高业务稳定性；完成性能评价自动化装置，完善应用性能评价体系，形成业务开发技术指标标准，并应用到 CI/CD 系统流程中；加强的线上问题的修复能力，将崩溃率提升至业界领先水平 针对以上目标，我们设计了一套大前端平台化开放系统，本文将详细阐述该系统技术方案。 技术演进路线 大前端的技术演进路线一般分为四...