架构理论

什么是架构?

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

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页