由于各种原因，好久没有写文章了。最近学习了一下架构设计方面的知识，拿来和大家分享一下。
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. 架构设计的目的
以上就是学习架构设计方面的知识啦，经过上面这些观察，了解，总出来一个架构设计的目的。架构设计的目的主要有两点：
- 解决系统软件带来的复杂度问题
- 应对业务或其他变化带来的麻烦
在做架构设计的时候，要紧紧贴合架构设计的目的，我们才能设计出够好的架构。
