从零开始学学架构-完结

操作系统的复杂度直接决定了软件系统的复杂度

操作系统和性能最相关的就是进程和线程

多进程多线程虽然让多任务并行处理的性能大大提升，但本质上还是分时系统，并不能做到时间上真正的并行

任务分配

任务分解

分支主题

系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元

数据+逻辑=业务，数据不正确就会导致业务错误（银行存钱栗子）

存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响

存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个，这就要求我们在做架构设计时结合业务进行取舍。

1. 独裁式

2. 协商式

3. 民主式

指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。

正确预测变化

完美封装变化

（1）从业务维度。对业务深入理解，对可预计的业务变化进行预测。

（2）从技术维度。利用扩展性好的技术，实现对变化的封装。

（1）使用分布式服务(框架)构建可复用的业务平台

（2）使用分布式消息队列降低业务模块间的耦合性

当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求；而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标。因此，低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束。也就是说，我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标，如果不行，就需要重新设计架构；如果无论如何都无法设计出满足成本要求的方案，那就只能找老板调整成本目标了。

低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标

安全本身是一个庞大而又复杂的技术领域，并且一旦出问题，对业务和企业形象影响非常大

1. 功能安全

2. 架构安全

规模带来复杂度的主要原因就是“量变引起质变”

1. 功能越来越多，导致系统复杂度指数级上升

2. 数据越来越多，系统复杂度发生质变

分而治之，各个击破”的方法策略

合适优于业界领先

为什么

简单优于复杂

复杂度体现

演化优于一步到位

方法

每个方案都是可行的，如果方案不可行就根本不应该作为备选方案

没有哪个方案是完美的。例如，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险

评价标准主观性比较强，比如设计师说 A 方案比 B 方案复杂，但另外一个设计师可能会认为差不多，因为比较难将“复杂”一词进行量化。因此，方案评审的时候我们经常会遇到几个设计师针对某个方案或者某个技术点争论得面红耳赤

最简派

最牛派

最熟派

领导派

“360 度环评”！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构设计原则 1“合适原则”和原则 2“简单原则”，避免贪大求全，基本上某个质量属性能够满足一定时期内业务发展就可以了

分支主题

子主题 1

业务分库

表单数据拆分

分支主题

分支主题

缓存穿透

缓存雪崩

缓存热点

分支主题

分支主题

I/O模型：阻塞、非阻塞、同步、异步

进程模型：单进程、多进程、多线程

每次有新的连接就新建一个进程去专门处理这个连接请求

共享进程内存空间

DNS负载均衡

硬件负载均衡

软件负载均衡

分支主题

轮询

加权轮询

负载最低优先

性能最优类

对于一个分布式计算系统，不可能同时满足一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三个设计约束

对某个指定的客户端来说，读操作保证能够返回最新的写操作结果

非故障的节点在合理的时间内返回合理的响应

当出现网路分区后，系统能够继续“履行职责”

分支主题

分支主题

Atomicity(原子性)

Consistency(一致性)

Isolation(隔离性)

Durability(持久性)

基本可用（Basically Available）

软状态（Sost State）

最终一致性（Eventual Consistency）

分支主题

（Failure mode and effects analysis，故障模式与影响分析）

给出初始的结构设计图

假设结构中某个部件发生故障

分析此故障对系统功能造成的影响

根据分析结果，判断结构是否需要进行优化

分支主题

面向流程拆

面向服务拆

面向功能拆

分支主题

分支主题

C/S架构、B/S架构（浏览器/服务器）

MVC架构、MVP架构

逻辑分层架构

对新技术特别热衷，紧跟技术潮流

对新技术包邮很强戒备心，稳定压倒一切，已经掌握某种技术，就一直用这种技术打天下

影响一个企业发展三要素：市场、技术、管理。业务是处于三角形中心，这三者都是为了支撑业务发展

基于业务发展阶段判断

分支主题

让需求、开发、测试等人员目标达成一致，用易于理解的沟通方式去进行

对于大型重构可能会进行好几个组或部门进行，始终要以整个项目为中心，不能有私心。换位思考、合作共赢、关注长期

优先级排序

问题归类

先易后难

循序渐进

需求介绍

需求分析

复杂度分析

备选方案

总体方案

架构总览

核心流程

详细设计

身份识别权限等

开发语言、公司标准等

硬件要求、服务器部署方式、组网方式

通常情况下，规划和设计的需求比较完善，但如果一次性全部做完，项目周周期可能比较长，因此可以采取分阶段实施，即：第一期做什么、第二期做什么，以此类推

判断力

执行力

创新力

分支主题

甲方要求必须运用某种技术

广度

深度

技术

个人成长

人生境遇

分支主题

学基础知识、学理论知识、学业界新的技术、研究开源系统、研究业界实践，既要有技术广度，又要有技术深度

培训、演讲、写博客、写书

源码不是第一步，而是最后一步。不要一上来就去看源码，而是要基本掌握了功能、原理、关键设计之后再去看源码，看源码的主要目的是为了学习其源码的写作方式，以及关键技术实现

开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求

逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。

更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。

更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。

更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。

分支主题