一、架构的含义
架构的本质是：实现业务目标的有所权衡和取舍的载体。
故：
- 架构的唯一评价标准是
是否契合业务目标。比如“谈论‘单体/分布式’，‘单点数据库/集群数据库’，‘非高可用/高可用’等方案选型，需要结合具体业务目标” - 架构演进的唯一动力是
解决现有架构与“当下或者可预见未来业务目标”的不契合问题。比如“业务需要持续提供服务，当下存在单点故障风险，故进行高可用改造”，“业务发展迅速，请求流量大幅度增加，故进行分布式集群高并发改造”，“业务需要稳定提供服务，避免单点过载，故进行负载均衡改造” - 脱离业务目标谈论架构就是耍流氓
特别需要注意的是，上述架构并非狭义的“软件系统架构”，而是广义的，还可能且不限于是：
- 公司组织架构。比如“总裁办 -> IT部，行政部，人力资源中心”
- 政府组织架构。比如“中央人民政府 -> 外交部，司法部，公安部”
- 电脑体系架构。比如“控制器，运算器，存储设备，输入设备和输出设备”
- 操作系统内核架构。常见的是“微内核架构”和“宏内核架构”两种架构方案
- 知识架构
二、业务目标
业务目标是具体情况具体分析，并且不断发展的，但是对于一些常见的、共性的业务目标会有较为成熟的解决方案，特别需要注意的是，解决方案的引入很可能会带来一些新的问题，比如“针对流量增加引入分布式高并发解决方案，可能会带来分布式节点一致性问题”，“针对快速读取热数据引入MySQL-Redis两级数据库解决方案，可能会带来MySQL-Redis数据一致性问题”。
接下来讨论“软件系统”这个业务目标。
2.1、架构基本单元进程实现
解决方案描述：
- 选用语言，比如Java，Go
- 版本控制，比如Git，SVN
- 项目管理，比如Maven
- 单元测试
2.2、流量增长应对
解决方案描述：
- 提高单点请求处理能力
- 集群化（分布式），可能带来“分布式节点的一致性”问题
2.3、数据库负载过大应对
解决方案描述：
- 读写分离，引入“读写一致性”问题
- 分库分表
2.4、单点故障导致不可用应对
解决方案描述：
- 高可用改造
2.5、流量在集群内节点的分配应对
解决方案描述：
- 负载均衡
2.6、热数据快速访问需求
解决方案描述：
- 采用MySQL+Redis两级数据库方案，引入“读写一致性”、“缓存穿透”等问题
2.7、监控度量需求
解决方案描述：
- APM
- InfluxDB + Grafana
2.8、集中收集日志数据需求
解决方案描述：
- ELK
- Log4j 2 + Kafka，引入“最多1次/至少1次/恰好1次”问题
另外还有且不仅限于以下这些业务目标（或者说解决方案对应的业务目标）：
- 微服务化改造
- 实现熔断降级限流
- 优雅停服
- 弹性伸缩
- 容器化部署
- 使用K8S管控容器
- Service Mesh改造
- 实现幂等性接口
- 引入分布式锁
- 引入分布式事务
- 引入分布式ID
- 接入配置中心
