这是我参与「第四届青训营」笔记创作活动的第10天

客户端架构设计和应用

本堂课内容

架构面临的问题（全新业务、历史包袱、技术熵增、信息流通）
常见的架构手段（业务抽象，分而治之、标准规范、组织管理）
架构演进的例子（解决问题、保持重构、迭代升级、应对衰退）
成为优秀架构师（技术储备、贴近业务、热爱代码、始终学习）

知识点介绍

架构面临的问题

一个产品总是要思考在成长期如何快速成长，在衰退期如何对抗衰老

架构的问题涉及多个不同的技术领域，包括前端、客户端、服务端等等不同的领域，在技术不断发展的过程中，出现了理解成本变高，预测难度变大的问题，所以只要业务继续发展，越来越复杂就是必然的趋势。

还面临着一些其他的问题：

期望高
事情难
责任大
疗效慢

典型的客户端架构-Android OS

应用框架层（APP开发者直接使用的接口层、UI的实现、数据的处理、资源的使用都是利用这一层的API）
Binder IPC（提供跨进程访问的能力，APP可以高效的访问由系统进程暴露的能力，APP进程与系统进程之间的通信是典型的CS模型）
系统服务（提供窗口管理、相机、音视频等重要的系统能力，包含各种子系统，内部逻辑十分庞大，往下调用HAL层封装的硬件能力，往上通过Binder暴露可以远程调用的API）
硬件抽象层（屏蔽底层不同驱动的差异，使得系统服务层可以快速适配不同的硬件设备）
Linux内核层（CPU、内存、唤醒服务等重要的驱动实现都是基于该层擦偶偶系统的核心实现）

典型的客户端架构——IOS

应用框架层
图形图像层
核心服务层
内核层

典型的客户端架构——Flutter

UI框架层（提供不同样式的组件和动画，声明式UI、采用了Dart作为编程语言，能够同时支持JIT和AOT，在开发调试和运行阶段都能有不错的效率提升）
引擎层（将上层定义的UI树转化成屏幕像素，提供平台调用接口和Dart虚拟机)
嵌入层（Flutter引擎需嵌入不同的平台；Android/IOS/Windows/Linux）

架构设计是为了解决特定领域不同发展阶段的业务问题，架构不仅面临技术的挑战也要应对组织业务膨胀的熵增

常见的架构手段

小的架构手段有——GOF设计模式、MVC、MVP、MVVM

架构模型	优点	缺点
MVC	模块职责划分明确，主要划分M,V,C三个模块，有利于代码的维护	View和Controller容易膨胀；View与Model没有完全分离
MVP	View和Model完全分离，可以修改视图而不影响模型，交互都发生Presenter； Presenter与View的交互是通过接口来进行的，方便但愿测试	页面逻辑复杂的话，相应的接口也会变很多，增加维护成本
MVVM	ViewModel与View的耦合更彻底 ViewModel只负责处理和提供数据 ViewModel里面只包含数据和业务逻辑，没有UI，方便单元测试	数据绑定使得程序较难调试，因为数据都是自动更新到UI

AOP和OOP

OOP	AOP
类：代码以函数和字段的形式封装在类中	类：代码以切点、属性、植入的形式封装在类中
函数：定义函数签名和函数体	切点：定义植入的锚点
函数体：定义函数的执行逻辑	植入：定义需要植入的逻辑
编译器：将源代码转化成可执行代码	植入器：将植入逻辑插入到锚点处

loC

直接依赖：一个对象A要完成其功能，通常需要依赖于B、C等对象，其具体实现方式就是要在对象A中构建其所依赖的对象B、C。这就相当于A控制了它所依赖的对象B、C

控制反转：打破A直接控制B这层关系，B对象的生命周期由loC容器来控制

大的架构手段

单体架构
分离架构
服务化架构
微服务架构
领域驱动架构

架构演进的例子

孕育期（做一个信息流产品，可以无限刷的列表……
婴儿期（产品功能开始变多，需要拆分模块……
学步期（业务场景变多，需要拆分业务……
- 表现层：接收用户输入，获取数据，呈现界面
- 业务层：处理业务数据、数据流转，安全检查
- 持久层：提供数据的增删改查能力
- 存储层：按照待定的格式存储数据
优点：
- 结构简单清晰，易于理解和管控
- 层次关系适合不同技能人员分工
缺点
- 对层级管控要求严格，灵活性低
- 为了解耦容易拆分出很多中间层
青春期（不同业务和模块混合，需要解耦……

事件驱动架构
- 事件：一个消息，譬如触摸了屏幕、点击了按钮
- 事件处理器：事件的实际消费者，对关注的消息进行定于，消息处理的过程很灵活，可以在当前处理器吞掉一个消息，也可以继续将消息交由其他消息队列处理
- 事件队列：消息队列，事件将以消息的形式发布到队列中，并设计特定的派发机制来处理队列中的消息
优点
- 使用广泛，容易扩展出不同变种
- 性能较好，支持消息的异步处理
缺点
- 缺少约束，消息处理器容易膨胀
- 处理链路容易变长，理解成本高
壮年期（业务变得更加内聚，需要灵活插拔……

微内核架构
- 宿主容器：一般不包含具体业务逻辑，而是从中抽象出模型，相当于一个运行环境，供不同业务以插件的形式在其中运行
- 插件：具体的业务实现，通过一定的技术手段挂载到宿主容器中，插件一般可以访问宿主的资源
优点
- 高扩展性，需要什么就开发什么
- 插件隔离，能够简化业务耦合度
缺点
- 对宿主容器的要求很高，且宿主不易扩展
- 插件的注册和通信机制通常比较复杂
稳定期（用户规模和团队稳定，历史包袱重……

不同形态的架构

架构演进	核心思想	优点	缺点
单体架构	快速组织界面交互、业务逻辑和数据之间的关系	快速成型、管理简单	依赖复杂、单点失效
分离架构	分而治之，拆分方式多种多样	业务分层更清晰、组件复用	强制遵循规范、业务依旧耦合
服务化架构	设立业务之间的接口契约	业务解耦更内聚	服务数量膨胀
微内核架构	配套插件和发现机制，业务动态发布	服务隔离可插拔，局部失效影响可控	管理成本高、调用链路长
领域驱动设计	战略设计从业务视角出发，建立业务领域模型；战术设计从技术视角出发，侧重于技术实现	解决复杂业务问题，架构随着业务发展	需要成熟的团队，经验高度抽象

成为一名优秀的架构师

定义方法——>确定架构——>方案落地——>结果复盘

个人总结

学习了和架构设计有关的相关知识以后，发现目前我的代码属于界面和业务逻辑混合的状态，如果想进一步开发，就需要把界面与代码分离也就是说要把前端和后端分开，那么前端只需要处理布局、控件、样式、简单计算，而后端只处理前端的请求，提供业务的数据。

学习过程中我还学习到了更多更先进的架构模型与它们各自的优缺点。

客户端架构设计和应用 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第10天