定义与实现解耦，运行时加载实现

代表性实现方式就是java里面的SPI机制。比如mysql的驱动mysql-connector-java里面有个MATA-INF/services目录，里面定义具体驱动类，这些驱动类都实现Driver类接口。

如下图所示：

驱动加载类如下：

• 系统的可扩展性可以遵循标准、识别、注册、运行总的法则去演化不同的具体的实现，可以根据实际的场景选择合适的方法，不再是 SPI，思维就会打开很多。如 Spring 通过 PostProcessor 开放了用户自定义的业务逻辑，它的流程也是遵循上面的八个字"标准、识别、注册、运行"。
• 什么是框架？：有固定的流程，并且对用户开放业务逻辑的半成品

固定流程+开放扩展点

• 架构思维：固定不变的流程，开放变化点。阿里 TMF 框架中的关键思想也有类似的表述。笔者所提的可扩展性架构设计方案就是从 SPI、插件模式中获取相应的思想，然后选择合适的方法去实现。

系统架构定义及分类

定义及分类

• 系统就是若干相互联系、相互作用、相互依赖的要素结合而成的，具有一定结构和功能，并处在一定环境下的有机整体
• 系统架构 = 要素 + 连接 + 解决特定问题
• 谈系统架构一定要指定类型，否则两个认识就不一致。
• 架构分类：

业务架构 : 定义业务战略、治理、组织和关键业务流程。

数据架构 : 描述组织的逻辑与物理数据资产及数据管理资源的结构。

应用架构 : 应用之间结构和交互的描述。

技术架构 : 描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力，包括 IT 基础设施、中间件、网络、通信、处理和标准等。

所以，聊系统架构要指定架构类型，因为不同的架构类型侧重点不一样，明显的业务架构和技术架构就不一样，业务架构偏重的是业务愿景、业务价值、业务流程；而技术架构偏重的是运用哪些技术组件来解决实际问题。

架构特性

• 目标性：目标是我们的灯塔，指引我们向什么方向走。

• 可分解性：这与分而治之是一样的意思，不管是系统架构在设计还是实施都具有可解性，一方面不同的人可以专注于某一方面深入研究；另一方面是可以并行工作，提升效率。

• 层次特性：层次特性是系统架构的基本特性，像网络协议、计算机系统结构，都是有一定的层次的，所以系统架构也有这样的层次。比如在业务架构中，笔者习惯按场景层、业务能力层、业务模型层、依赖层来划分。

参考文章https://www.infoq.cn/article/fwhQ-dIN2xTUH6zNLYZp

架构目的

我们已经知道系统架构是什么，有必要讲一下系统架构的目的，即为什么要进行系统架构。对于简单的系统而言，可能没有什么所谓的系统架构，这里的"没有"可能对我们来讲是常识，如简单的系统分层。系统架构的本质目的从公式定义中就可以看出：解决特定的问题，这个特定的问题有技术上的问题、业务上的问题、项目管理上的问题。

架构难点

技术难点

在有些场景下，技术会成为架构的难点之一，如笔者之前在阿里店铺团队，双 11 高达十几万的 QPS，如果处理不当，可能就会导致访问的店铺页面打不开。所以，对于高并发场景，我们面临很多挑战，

业务难点

在业务架构的基础上，笔者提出业务能力地图的观点，如何让一个新人以最少的成本熟悉业务系统，除了业务系统设计得非常好，有详细的文档可参考外，还要有可视化的能力地图，从一个业务场景出发，中间涉及到的调用逻辑全部通过可视化界面展示出来，一个新人就可以很清晰地知道整个业务流程如何运转，先从宏观上理解产品、业务运转，再去看代码要轻松得多。

项目难点

一个大型系统设计的业务方比较多，如果系统架构方案已经产出，剩下的就是落地执行，项目管理也有可能是我们的一个难点，如何协调资源、处理冲突、关键项目里程碑、问题跟踪和解决、上线灰度策略、业务监控…这些在系统架构设计时都要考虑到，并且在执行的过程中要有反馈。

一个项目如果没有人管理延期的风险会很大，其实大部分开发不善长做管理、沟通等事情，在一个组织里，不同的人、不同的事形成一个较复杂的环境，所以也有人说管理是一门艺术。

应对架构方法

• 系统性思考

我们考虑的目标是系统，不是单一的点，所以要系统性思考。这个听起来比较虚，还是拿一个技术架构中的秒杀场景来说明。秒杀的本质是有限的资源应对大量的请求，解决这个问题资源肯定不能加大，就 100 个商品，不可能加到 10000 个商品。所以怎么应对大量的请求就是解决问题的关键点，我们可以直接从两个方面来考虑：用户和系统两个角度。用户大量的请求直接涌入，系统可能承担不住，能不能打散用户请求？系统方面能不能更快的处理用户请求，之前要 100ms 处理完的，能不能用 10ms 处理完？所以这样分析下来，从接入层、处理层、存储层考虑，而不是单一考量。

• 分解

一个复杂的问题分而治之是一个宝贵的经验，同样在系统架构中也经常使用到，还是拿上面的例子继续说，上面从用户和系统两个角度考虑，那么从用户角度如何去做？从系统角度又该怎么去做，两个独立的可以单独拿出来设计。技术架构可以按照这种方法来做，业务架构也会使用分解的方法，业务流程的分解，分解出更小的流程，从流程中找出产物是什么。

• 抽象

抽象这个词本身就很抽象，经常说就不知道它是什么，笔者对抽象的理解就是抽出来要像，如人在医院中重要的是身份信息+健康信息，在学校中重要的是身份信息+成绩信息，在工作中重要的是身份信息+工作经验+KPI，所以不同的场景要抽象出本质的东西来描述事物。那么复杂的一个系统，要抓住核心的点，可能核心点不超过 10 个，这样就大大降低理解的复杂度了。

• 模式

好比写作一样，有不同的模式，架构设计也有不同的模式，这种模式是约定俗成的，一看就能理解，常见的是分层架构模式，一些比较少用的模式了解即可，把重要的精力花在常见的模式上，遵循二八原则。

用一句话概括系统架构的方法：明确我们要解决的问题，通过系统化的思考方式找到关键的点，对不同的关键点进行分而治之，再通过抽象找出要素，最后通过一定的模式表现出来。

原文链接:https://blog.csdn.net/hanruikai/article/details/117282506