架构理论

什么是架构？

1. 系统与子系统关系？
2. 模块和组件关系？
3. 框架和架构？

架构设计的目的

解决系统复杂性带来问题

架构设计复杂来源

高性能

• 单机： 主要是操作系统对硬件的资源调度。为了提高性能，操作系统喂我们提供批处理机制、进程、线程、等等，但是IO的操作、进程的调度是会降低性能的；
• 集群:当一台服务器无法满足性能要求时候，就需要多台机器集群实现。但是集群实现存在很多技术复杂度。例如任务分配，不同任务依据任务分配器分配道不同机器来运行，任务分配器要考虑任务分配算法，以及和服务器之间连接检测、中断处理等等；任务分解，同一个业务线可以每个机器执行一部分，最终协同完成任务；等等

高可用

• 概念：无间断的提供服务，达到XXXXX个9
  这个太难了，出现终端服务的因素太多，例如硬件故障、软件BUG、网络波动、等等
• 存储高可用：一份数据多地方存储；这个会很苦难。因为我们要解决如何避免数据不一致情况。因为，往往数据多服务器 甚至机房的同步都需要网络动态来做，此时出现问题的概率就会增加，也是经典CAP(Consistency Availability Partition tolerance)理论意思；即一致性、可用性、分区容错 只能满足两个；
• 计算高可用:服务多台部署，任何一台功能一样：例如zookeeper的一主多备

可扩展

• 目的：系统满足将来新的需求以及需求变化所拥有的扩展能力。当有新的或者紧急需求来的时候，系统不需要或者少的改动就可以快速支持，特别是再初创或者业务快速发展公司，此种情况很多，也是目前我们云采系统所必须具备的能力
  解决方案：
• 善于预测未来业务变化

1. 每个设计点都考虑扩展性：例如系统要支持Mysql,oracle,Hbase等，要支持Http,还要支持protocoBuffer等等；
2. 不能完全不考虑扩展性：例如表结构设计，代码风格，设计模式运用，这些都是针对扩展性而产生的一些方法论，对于后期扩展有很好支持，所以我们要遵守；
3. 所有的提前预测也可能出现失败，这些很正常。再牛的团队也不能完全预测所有未来的业务发展
   因此，如何准确预测变化，只能依靠我们的经验，代码编写，需求的预测，系统设计，有些东西前期是可以预测出来，进而进行提前规避的。例如我们山西建工的功能开发，前期若直接硬编码，就不会又很好的扩展性

• 前期封装变化：：抽离变化的逻辑，保留稳定的逻辑。当然，这也是一个渐变的过程。前期很难完全正确的抽离两层，只能随着业务不断发展，逐步稳定，最终沉淀下来。也反映了系统架构从简单到复杂再道简单的一个周期

低成本

再结果不变情况下，采用更低的资源投入，满足要求。当然，也提高了系统的复杂度.这往往需要技术创新来实现。例如solr满足了关系数据库不能复杂查询；NOSQL满足了关系数据库无法应对高并发带来压力；脚本语言解决了动态语言不能快速实现小沟通问题；MQ解决系统并发性；能加硬件解决问题，就不用投入资源解决性能；能使用10个服务器就不用使用1000个服务器等等

架构设计原则

合适原则

考虑团队资源：我们像开发一个淘宝系统？我们想自研发一个MQ?我们想自研发一套ERP？试想，目前业务到了这个阶段吗？公司有必要投入资源做这些事情吗？后期的维护、运维团队有能力把控这些吗
好的系统一定是迭代完善出来的: 例如我们自己开发个类似支付宝的东西，不是说拍个脑门，加个班就出来了，支付宝之所以能抗住双11的流量，不知道他自己踩了多少的坑，后面有多少类似刑探专家、安全专家、心理学专家在支持这；所以，不要被表面迷惑了，要看到事物的本质；
业务驱动技术，技术服务业务。量变引起质变。当前技术的选择一定是要符合当前业务发展的，当业务发展到一定阶段，自然会催生新的技术出现。为什么支付宝是淘宝的而不是百度的？为什么RocketMQ是阿里的而不是其他公司，难道真的其他公司没人能做出来？一定是淘宝发展到某些阶段，必须依靠新的技术来支持业务快速发展，而产生了这项技术。包括谷歌 微软都有自己独有产品。
因此，合适原则要求我们考虑当前公司人力资源、业务发展、等等综合因素，最终设计一套架构能否快速落地，附合当前业务，才行。任何脱离业务的架构设计都是耍流氓。

简单原则

简单就是稳定”这个原则非常关键，应用各个方面，产品方案设计、代码逻辑设计、表结构设计等等，其实很多技术本质都差不多，如果我们能以一个简单的方案实现其不更好？例如MQ云采目前基于数据库来做，就可以满足当前业务。因为，架构设计负责，参与的组件就会越多，越有可能出现某个组件故障。某个组件改动，又会影响上下游的组件，而且定为一个问题，也困难很多。所以，万事追求简单，以解决问题为导向。切忌简单问题复杂化。

演化原则

系统最大特点是不断变化。Window系统从1.0道目前win10几乎就是连个系统。不要期望设计一个系统一步到位，随着业务发展，一点也不变。因此， 系统架构设计一定是先满足目前的业务场景，随后在业务的不断发展过程中，不断优化重构，保留好的设计，去掉之前因为考虑扩展而做的无用设计，这样到后期，保留下来的一定是附合当前业务的逻辑、设计。因此，架构不是设计出来的，是演化出来的