架构系列-概述

一、概述

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）演化原则：演化优于一步到位。首先要满足当前的业务需求，不贪大贪全，照搬大厂架构。要遵循演化原则。

未经允许不得转载：任鹏个人博客 » 架构系列-概述