面向复杂度架构设计的思考

-- 学习消化华仔的课程

何为复杂度

• 需要解决的问题，才具有复杂度，不需要解决的问题，自然没有复杂度。所以我们需要聚焦需求，不要凭空去制造复杂度

• 复杂度的外部原因：

• 业务变化快：互联网项目业务日新月异，软件需求的迅速变化会对系统带来很大的不确定性；甚至项目还没有上线，需求就变了；所以要求代码和架构具有可扩展性

• 需求不明确：新的业务场景，往往需求不明确，需要投石问路，软件产品要能够聚焦 MVP，采用迭代的方式，迅速得到市场和用户的反馈；所以，敏捷软件开发又迎来了新一轮的高潮

• 用户规模大：移动互联网的兴起，用户规模迅速壮大；大数据量高并发的访问，软件的复杂度会直线上升

• 用户体验要求增加：用户的体验需求越来越高，前端需求很明显在增加；同时，后端服务的响应时间，也有了越来越高的要求

• 复杂度内部原因：

• 复杂度转移：随着云平台的兴起，复杂度从基础设施的维护转移到服务的治理。我们不需要花费大量的精力耗费在硬件的维护；但是服务规模的增大，微服务的治理难度正在迅速提升

• 团队人员的技术能力，团队的流动，团队的培养也时刻带来挑战

• 业务的迅速变动，需要业务团队与开发团队的沟通频率加大

• 架构和代码质量的要求与项目上线的时间的冲突

• 架构和代码质量的要求与预算的冲突

• 系统安全：为了保证系统安全，会带来复杂度，而且也只能做到相对安全，没有绝对安全

• 复杂度是可拆解的，任何复杂的问题都可以拆分为多个相对复杂度变低的问题

• 架构设计的无标准性，也是一种复杂。架构设计没有唯一标准，所以有人称：架构设计是一种艺术设计

何为简单

• 简单不是简陋，不是功能的缺失

• 简单就是要让人容易看懂：例如代码简单易读，就是要职责单一，分层清晰，代码能够体现出来业务逻辑，变量命名清晰；反例就是：if else 一堆，看不懂；所以简单，并不会减少时间

• 简单就是耦合小，功能边界明确，调用简单：所以就是高内聚，低耦合，DDD 可以解决这类问题

• 简单就是不过度设计，不耍酷

• 简单就是适合即可，不要想着以后 10 年的需求（例如：现在用户 10w，却想着设计 1 亿用户的系统），先做出来，持续迭代
  

何为面向复杂度架构设计

• 面向需求进行架构设计：首先需要申明：只有需求范围内的问题，才是我们需要解决的问题；不要凭空创建需求，架构需要紧贴公司业务

• 面向系统核心进行架构设计：系统的核心功能，需要更多的考虑，考虑的因素多，架构设计自然会复杂；所以要能够分辨系统的哪些部分是核心功能，需要重点设计

• 面向拆解复杂度的方式进行架构设计：架构师的职责是将复杂问题进行分层和拆解，让问题变得简单

• 面向系统复杂部分架构设计：架构师需要分辨系统哪些部分比较复杂，哪些部分风险比较大；需要将复杂的部分重点考虑

架构设计环

• 判断：

• 架构师需要理解需求，分析需求，澄清需求

• 架构师需要从需求判断出系统的核心，找到复杂度

• 如果需求无法实现，架构师需要尽快反馈给业务，减少项目的风险

• 拆解：

• 复杂的问题是可以拆解为简单的问题，架构师需要将复杂问题拆解为简单问题

• 架构方案没有绝对，需要提出多种方案

• 取舍：

• 选择其中一个方案，需要结合项目背景、团队背景、技术背景等综合考虑

• 取舍是一个协作的过程，需要与其他架构师、leader、boos 进行沟通，他们会有不一样的视野

• 取舍的过程，是一个学习的过程，根据获取的信息，可以返回对方案进行进一步优化

• 实现：

• 架构师的产出是实现，而不是架构图，所以架构一定要是可实现的

• 架构师需要参与到实现过程，根据实现过程中遇到的具体情况，对架构进行调整

• 架构师需要积累实现经验，以便于设计出可实现的架构

架构设计三原则

• 合适原则

• 合适优于业界领先

• 需要考虑的背景：资源、时间、业务背景、公司技术风格和背景、技术能力等

• 简单原则

• 简单优于复杂

• 简单易懂，边界清晰

• 简单容易运维和扩展

• 简单是门艺术
  

• 演进原则

• 演化优于一步到位

• 需求可变和环境可变

• 合不合适，试了才知道