架构设计系列之基础：初探软件架构设计

11 月开始突发奇想，想把自己在公司内部做的技术培训、平时的技术总结等等的内容分享出来，于是就开通了一个 Wechat 订阅号（灸哥漫谈），开始同步发送内容。今天（12 月 10 日）也同步在 CSDN 上开通这个系列的文章，进度上当前比订阅号慢了，我争取尽快同步，想提前看后面内容的朋友可以同步关注订阅号。

前言

欢迎来到软件架构设计的世界，这是一次面向有志成为架构师的研发工程师的学习和分享交流的机会。

本系列内容将结合理论和实践经验，探讨软件架构的基本知识、设计原则和最佳实践，旨在和大家一起更好地理解软件架构设计的重要性和成为架构师的路径。

一、架构的基础

我们都知道编写和调试一段代码直至成功运行，这是需要一定的知识和技能，但并不需要特别高深。相比之下，软件架构却是一件非常困难的事情，它需要深入的专业知识和丰富的经验。

所以并不是所有的程序员都可以成为架构师，这需要有独特的思维和独到的见解。

一个没有良好架构的系统会带来严重的后果：

组件之间的关系错综复杂，耦合紧密，任何一个小的改动都需要数周的恶战
整个系统的设计可能差到令人无法忍受，充满了腐朽的设计和裹脚布般的恶心代码
不仅会影响系统的质量和性能，还会导致整个团队士气低落，程序员生不如死

因此，为了提高系统的质量和性能，我们需要有一个良好的系统架构。需要一位专业的架构师，他需要：

具备深厚的技术知识和经验
具备强烈的责任感和领导力
需要能够从宏观的角度看待整个系统
为系统的未来发展作出预测和规划

1 、架构是什么

架构是软件系统的顶层结构，是对软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

2 、架构的目标

使用最小的人力成本、最高的质量、更高的客户满意度来满足构建和维护该系统的需求。总结来看就是四字目标：多、快、好、省，其中涵盖了效率、成本、稳定、运维、演进、容错、安全等多个方面。

3 、架构的理论目标

Reliable - 可靠性
Secure - 安全性
Scalable - 可扩展性
Customizable - 可定制化
Extensible - 可伸缩
Maintainable - 可维护性
Custom Experience - 客户体验
Time to Market - 市场时机

二、架构的职责

架构需要将不变的部分从变化中抽象出来，沉淀为稳定的组件，同时管理多个组件之间的依赖，识别、定位、管理组件的边界和上下文，让变化更容易暴露和识别。

此外，架构还需要考虑如何管理多维度的变化，以及如何将业务逻辑变成可配置的易变更的实现方式。

三、架构的类型

如上图所示，架构分为：

业务架构：业务架构师（业务领域专家）负责，涉及对业务的定义和划分，属于顶层设计，它影响着组织结构和技术架构
应用架构：应用架构师负责，根据实际业务场景，设计应用的拓扑结构，制定规范、定义接口和数据交互协议等，尽量把应用的复杂度控制在一个可接受的范围内
系统架构：系统架构师负责，根据业务情况综合考虑系统的非功能属性，包括性能、安全性、可用性、稳定性等，然后做出技术选型；而对于分布式系统架构设计，还需要解决服务器负载、分布式服务注册和发现、消息系统、缓存系统、分布式数据库等问题以及 CAP 的权衡问题
数据架构：数据架构师负责，关注数据的收集、处理以及提供统一的服务和标准。其目的是统一数据定义规范，标准化数据表达，形成有效易维护的数据资产，搭建统一的大数据处理平台，形成数据使用闭环
物理架构：关注软件元件在硬件上的部署，包括机房搭建、网络拓扑等
运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系；借助技术手段控制和优化成本；通过工具化及流程提升运维效率，注重运营效率；制定和优化运维解决方案，包括但不仅限于柔性容灾、智能调度、弹性扩容和防攻击、推动及开发高效的自动化运维和管理工具、提高运维的自动化程度和效率