架构设计初识

由于各种原因，好久没有写文章了。最近学习了一下架构设计方面的知识，拿来和大家分享一下。

1. 架构是什么

架构是什么，大家能都说出一二，每个人对架构的理解又不尽相同。但对于架构，我们有几个模糊相似的概念需要知道，分别是：系统与子系统，模块与组件，框架与架构。来说说这几种概念的区别。

1. 系统与子系统

1. 系统

维基百科的解释是：

系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。

抽象成三部分，分别为：关联（有关联的个体），规则（根据某种规则运作），能力（完成个别原件不不能单独完成的工作，新能力）。

2. 子系统

根据字面意思，和系统定义相同，只是范围更小。举个例子，如淘宝系统，里面有资金，购物，会员系统等，都是一个个子系统

2. 模块与组件

模块和组件都是系统的组成部分，但是从不同的角度拆分，有了不同的名称

1. 模块

从逻辑单元拆分，得到的就是模块。主要用与职责分离

2. 组件

从物理单元拆分，得到的是组件。主要用于单元复用

3. 框架与架构

1. 框架

框架更多用于规范，如 MVVC，MVP，如实现 MVC 的 Spring 框架

2. 架构

架构更多的关注的是系统的结构

2. 系统复杂度

现在，我们在设计架构或系统时，关注的点有很多，安全，可用，性能等，主要总结下来，有 6 点，分别是：高可用、高性能、可扩展、安全、低成本，规模。接下来对这几点进行总结。

1. 高可用

对于用户量大、访问量高、重要的系统来说，高可用总是必不可少的。高可用分为二部分，分别是计算高可用和存储高可用。

计算高可用主要是通过增加计算单元，如：多机部署。存储高可用主要通过备份数据，保证数据一致性，但数据间同步，又是新的问题。不管是增加计算单元，还是数据备份，都未系统带来了新的复杂性。但这些手段都是用来减少和避免不可用问题，而不是用来解决问题

2. 高性能

高性能复杂度主要体现在 2 个方面，分别是：单机高性能复杂度，集群高性能度。

1. 单机高性能复杂度

单机提高性能主要体现在：多线程，多进程。多线程在数据同步问题，多进程在通信方面都会带来复杂度

2. 集群高性能复杂度

集群复杂度主要体现在：任务分配，任务拆解。任务分配是在集群中，对任务如何分配是一个问题。任务拆解是因为在集群中单节点性能达到最大的时候，只有通过将任务通过过系统处理，来提高性能。

3. 可扩展

可扩展的复杂度主要体现在：预测变化，抽象在一直改变。

只有预测未来业务的变化，才能设计出可扩展的系统。如：系统是否需要分库分表，现在不需要，随着业务增长需要吗?..等等。

对系统抽象出来的代码也会随着业务的改变不停的改变，只有进行深层次抽象才能兼容多种业务逻辑。推荐多使用设计模式。设计模式主要用来将变化和稳定分离。

4. 低成本

低成本复杂度主要体现在与高可用相互违背，如：高性能可能需要引入新技术，自研新框架，或增加机器，这些都会带来成本的增加。但低成本是架构设计考虑点，但不是首要点。

5. 安全

系统安全也是需要考虑。主要分为从架构层面和代码层面。

架构层面需要考虑架构是否安全，如 Ddos 攻击。 代码层面要考虑功能是否安全。如：Sql 注入，RSS

6. 规模

规模的复杂度主要体现在：规模增大，会量变引起质变。如用户从 1W 变成 10W，100W，就要考虑：高性能，高可用等。

3. 架构设计三原则

架构设计的主要原则体现在三方面，分别是：合适大于业界领先，简单优于复杂，演化优于一步到位。

1. 合适大于业界领先

在做架构设计的时候，要选择业务合适的，而并非业界领先的。如：设计一个学生管理系统，看到大公司都是用微服务，那我们就用是用微服务。这样并不合适，因为学生管理系统在用户量，功能上等都打不到这样的量，单机就可以，可能需要考虑数据问题，但这在数据层面解决即可

2. 简单优于复杂

在进行架构设计的时候，复杂的设计，带来的逻辑关系，或业务处理关系就会变得更复杂。如：把一个系统拆分成 10 个系统交互，这样带来的问题远远大于一个系统。并且复杂的系统排查问题，就需要更多的时间，花费更多的精力

3. 演化优于一步到位

任何事物是符合生物进化论的，架构设计也是如此。一开始我们设计架构，并不能就"一步登天"。主要体现在：

• 人力，资源方便过多的投入会浪费资源

• 业务在不断变化，并不能完全预测业务

在业务发展的的时候，会有更多的收入，这时候，再花费更多的资源，取其精华，去其糟粕，进行重构，这样也是合适的，收入和投入是成正比的。避免在一开始，进行假大空设计，到头来，业务并达不到量，浪费设计。或系统过与庞大，导致系统无法上线等问题。

4. 设计流程

设计流程主要也分了三部分，分别是：识别复杂度，设计备选方案，设计系统详细方案。

1. 识别复杂度

根据业务的需求，将目前主要的复杂问题罗列出来，根据团队，业务，技术等综合情况排序，选出最先需要解决的复杂问题。

2. 设计备选方案

在识别出系统复杂度问题后，我们就需要出设计方案，但是设计方案不能只有一套，需要设计出 3-5 套。设计方案太少，可能会由于自己的疏忽，见识等问题，未能覆盖复杂问题。设计的太多会影响精力，耗费大量的时间。

设计出的备选方案，需要有较大的区别，而不是一些无关紧要的区别，如：消息中间件是采用 Kafka 还是 RocketMQ，而不是消息延迟 15s 还是 30s。

3. 设计出系统的详细方案

在经过沟通后，选择出来一套整体看起来可行的方案，这个时候我们就需要给出更多的细节，分步骤，分方式，分系统降低系统的复杂度。在设计详细方案时，可以找出系统整体能否实施部署等问题。在根据出现问题，做出一些细节问题的修改。

4. 架构设计的目的

以上就是学习架构设计方面的知识啦，经过上面这些观察，了解，总出来一个架构设计的目的。架构设计的目的主要有两点：

• 解决系统软件带来的复杂度问题

• 应对业务或其他变化带来的麻烦

在做架构设计的时候，要紧紧贴合架构设计的目的，我们才能设计出够好的架构。