架构系列-概述
一、概述
1、架构是顶层设计;框架是面向编程或配置的半成品;组件是从技术维度上的复用;模块是从业务维度上职责的划分;系统是相互协同可运行的实体。
2、架构是为了应对软件系统复杂度而提出的一个解决方案。个人感悟是:架构即(重要)决策,是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人,财,物,时间,事情等)。架构无优劣,但是存在恰当的架构用在合适的软件系统中,而这些就是决策的结果。
需求驱动架构。在分析设计阶段,需要考虑一定的人力与时间去"跳出代码,总揽全局",为业务和IT技术之间搭建一座"桥梁"。
架构设计处于软件研制的前期,一方面,越是前期,如有问题,就能够越早发现,修改的代价也就越低;另外一方面,也意味着,软件实施后期若有架构上的修改,也需要付出更多的代价。
1)架构是为了应对软件系统复杂度而提出的一个解决方案。
2)架构即(重要)决策
3)需求驱动架构,架起分析与设计实现的桥梁
4)架构与开发成本的关系
二、架构复杂度来源
3、系统复杂度来源:高性能。从单机到集群的服复杂度来源:
1)任务分配:F5、交换机、LVS、Nginx、HAProxy等
2)任务分解:拆成服务。业务本身不变的情况下性能有上限,系统拆封可以逼近这个极限,但不能达到。过多的服务调用会降低性能。
4、系统复杂度来源:高可用。复杂度通常高于高性能,因为涉及到知识点更多。
1)计算高可用:冗余。
2)存储高可用:难点不是如何备份,而是如何减少数据不一致带来的影响。分布式领域里有CAP理论,即一致性,可用性,分区容错性只能取其二。
3)状态决策:
(1)独裁式,仍有单点问题;
(2)协商式,两台备,然后自行决策选出主,在主备连接中断后变成两主,不符合预期;
(3)民主式,如zookeeper,节点自行投票,为解决脑裂问题,需要投票过半数。但在1、2、3节点故障后,4、5仍可用,但投票不过半数,无法选主,系统不可用。
5、系统复杂来源:可扩展性。应对变化的适应能力。不能不做预测,预测也可能出错,也不可以过度预测。封装变化,隔离可变性。
6、系统复杂度来源:成本。高性能高可用意味着更多的机器,当规模达到一定程度后,成本却就是考虑因素之一了。低成本的架构方案意味着引入新技术或开发新技术。开发新技术复杂度更高,如HHVM,kafka等。
7、系统复杂度来源:安全。分为功能安全如windows漏洞SQL注入等,和 架构安全如防火墙ACL等。防火墙性能低,目前没有很好的办法,更多是靠运营商清洗。
8、系统复杂度来源:规模。分为功能规模和数据规模。数据规模是数据量越来越大发生质变,比如mysql,超过五千万行后要开始分库分表。
三、架构设计原则
1、三大原则:合适 > 演化 > 简单 这个优先级。
1)合适原则:合适优于业界领先。没那么多人、没那么多积累、没那么卓越的业务场景。
2)简单原则:简单优于复杂。结构的复杂性、逻辑的复杂性。
3)演化原则:演化优于一步到位。首先要满足当前的业务需求,不贪大贪全,照搬大厂架构。要遵循演化原则。