这是我参与「第四届青训营」笔记创作活动的第11天
课程主要内容
- 架构面临的问题
- 常见的架构手段
- 架构演进的例子
- 成为优秀架构师
架构面临的问题
产品和架构的生命周期
不同技术领域的架构问题
还有一些其他挑战
只要业务继续发展，越来越复杂就是必然趋势。
理解成本变高
- 宏人的规模是不好理解的
- 复杂的结构是不好理解的
预测难度变大
- 务变化不可预测
- 技术变化不可预测
期望高
- 良好的顶层设计，从上到下有统─的认知
- 遵循共同的规范，写出让人舒适的代码
- 有没有“劳永逸”的设计，可保基业长青
- 什么时候能从架构工作中找到成就感
责任大
- 设计不合理：谁写的，看小爷我推到重来
- 使用不规范：压根就不该这么用
- 逻辑太晦涩：尼玛谁看得懂
- 编码坑太多：特么是隐藏技能啊，悄无声息改代码
事情难
- 业务历久弥新，历史包袱叠加新的场景
- 随便动动刀子就拔出萝卜带出泥
- 技术栈层出不穷，老朽学不动了啊
- 一方面要保持成熟稳定，一方面要积极探索落地
疗效慢
- 影响复杂度的因子众多，单个因子优化不足以撼动
- 没有一载，一理搞不下来
- 没有特效药，长期在隐隐作痛中前行
- 往往也只是开了一个“方子”，想要根治得长期健身
典型的客户端架构–Flutter
UI框架层
提供不同样式的组件和动画，声明式UI。采用了Dart作为编程语言，能够同时支持JIT和AOT，在开发调试和运行阶段都能有不错的效率提升
引擎层
将上层定义的Ul树转换成屏幕像素，提供平台调用接口和Dart虚拟机
嵌入层
Flutter引擎需嵌入不同的平台:Android/iOsWindows/Linux等
常见的架构手段
不同架构手段的共同目标是高内聚低耦合
找到适合业务场景的架构而不是炫技滥用
一个复杂的系统是多种架构模型的组合体
小的架构手段
GoF设计模式、MVC、MVP、MVVM、AOP、IoC……
| 架构模型 | 优点 | 缺点 |
|---|---|---|
| MVC | 模块职责划分明确。主要划分层M,V,C三个模块，利于代码的维护 | 1. View和Controller容易膨胀 2. View与Model没有完全分离 |
| MVP | 1.View与Model完全分离，可以修改视图而不影响模型，交互都发生Presenter 2.Presenter与View的交互是通过接口来进行的，方便单元测试 | 页面逻辑复杂的话，相应的接口也会变多，增加维护成本 |
| MVVM | 1. ViewModel与View的耦合更彻底，ViewModel只负责处理和提供数据 2. View Model里面只包含数据和业务逻辑,没有U，方便单元测试 | 数据绑定使得程序较难调试，因为数据都是自动更新到UI |
大的架构手段
架构模型
- 单体架构
- 分层架构 将业务逻辑划分成若干层，每一层保持特定的角色，下层提供API给上层调用
- 事件驱动架构 将业务逻辑抽象为事件的生产和消费，支持异步处理。是一种分布式架构模型，通常具备高扩展性和适应性
- 微内核架构 将业务拆分为核心系统和插件，譬如:浏览器应用、各种IDE工具，都有一个宿主，并且支持扩展各种各样的插件
- 微服务架构 将业务拆分为多个独立的服务单元，通过服务注册和发现机制，多个服务可以互相调用，单个服务的下线，不会导致整个系统崩溃
后记
通过今天的课程学习了架构面临的问题以及常见的小、大架构手段，了解了一些架构模型，为之后的课程学习打下基础。
