大家好，我是老猿，今天继续专题【老猿说架构】，文章仅代表作者观点，如有不同观点论述欢迎拍砖交流。好，废话不说，直接进入主题。
上篇讲到系统架构设计核心是解决软件之熵带来的问题，那么架构设计前一定要对业务要有全面深入理解全局把握及未来发展评估，在此基础上进行抽象、分解、建模、构建设计，在我看来就是系统架构设计具备三种思维，具体详见下面讲解。
思维1：识别系统核心复杂点（软件之熵）
系统的复杂度如何识别呢？那么首先我们必须全面准确理解业务当前和近期（一般1-2年）对系统容量指标的要求，也就是我们熟悉的容量指标：
高性能（高并发）
满足业务的增长
追求良好的用户体验
高可用（经常讲的N个9）
系统的服务稳定性和数据一致性
可扩展性
能够适应未来一定业务发展
规模
数据规模和未来数据增长速度带来的影响
业务功能规模不断膨胀的适应和扩展实现，即是降低架构腐化速度。
安全
各种应用安全漏洞、数据安全存储、传输和显示脱敏等
以上系统容量指标的要求越高系统实现的复杂度接越高，那么我们要根据业务当前和近期（一般1-2年）对系统容量指标的要求做出适用的系统架构设计，切忌过渡设计，比如一个文章发布系统，初期对系统容量的指标要求基本是适应多种类型文章发布和文章访问的速度，做好文章数据结构变化的数据字典支持及引入CDN、文章数据缓存实现基本就够了。
思维2：业务逻辑和系统控制逻辑有效分离
上篇讲到软件系统架构就是系统的子系统、模块、组件的分解实现同时处理好他们协作运行关系，那么就要识别出系统实现的业务功能和非业务功能（即是系统控制逻辑）并做好他们的有效分离实现，这样做的好处就是方便管控系统复杂度带来的影响，比如微服务架构spring cloud在这方面设计是做得很好，如网关层一般担当非业务功能实现，比如统一路由、异常处理、权限校验和熔断降级、限流限速流控方面的处理，微服务之间的发现、调用的负载均衡及熔断降级都有对应的组件实现，同时给到对应服务治理组件的实现，比如服务调用的全链路追踪等，这样就很好地做到了业务逻辑和系统控制逻辑有效分离，让开发人员集中做好系统业务子系统或模块及组件分解和实现，从而有效地管控好软件复杂度带来的影响，方便支持实现系统的高性能、高并发、高可用、可扩展性。
思维3：传输、计算、存储的抽象
任何系统动作实现都是输入、计算、存储和输出，那么系统架构设计最大的抽象就是设计好传输控制组件、业务计算组件分解与协作、数据存储的组件实现，也是对第二个视角做好全系统架构的抽象、分解和建模。
文/老猿，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系老猿。
