2022.20 架构设计随思

最近在做一个系统的设计，对软件架构设计又有了一些学习思考，就把当下思考认同的一些点记录一下。

需求总是会不断变化，软件架构要根据业务发展不断变化，在做架构设计时不要试图一步到位设计一个完美的架构，能应对将来业务的所有变化。而应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，不断减少系统的 “熵”，使系统不断进化。

架构设计是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。把系统拆分为各个子系统 / 模块 / 子模块，拆的时候，首先要解决每个模块的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起。拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

要基于具体的场景设计架构，没有最好的架构，只有最合适的架构。看过一篇文章中说到一个案例，在案例的场景用memcache做搜索更好，而不是ES、Lucene等，不要想当然的做架构，一说到全文搜索就要用ES，要结合实际的需求场景做设计。要了解你的用户以及他们的目标，然后基于此来平衡你需要做哪些事情。用户是新手、专家还是偶然的用户？极客喜欢扩展点，开发者喜欢示例和脚本，而普通人则喜欢UI。

无状态的系统的是简单可扩展的的，要尽可能做无状态的设计。

时刻要想投入产出比（ROI），先完成设计，再持续优化改进。要迭代着去做事情，有敏捷开发的思路。

在不知道用户将会如何使用我们的产品时，要拥抱MVP（Minimal Viable Product），最小可运行版本。挑几个很少的使用场景，然后把它搞出来，让用户使用，然后基于体验和用户反馈再决定下一步要做什么。