weixin_45061570的博客

合适原则合适原则宣言：“合适优于业界领先”。简单原则简单原则宣言：“简单优于复杂”。演化原则演化原则宣言：“演化优于一步到位”考虑到软件架构需要根据业务发展不断变化这个本质特点，软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大：首先，生物要适应当时的环境。其次，生物需要不断地繁殖，将有利的基因传递下去，将不利的基因剔除或者修复。第三，当环境变化时，生物要能够快速改变以适应环境变化；如果生物无法调整就被自然淘汰；新的生物会保留一部分原来被淘汰生物的基

经过架构设计流程第 1 步——识别复杂度，确定了系统面临的主要复杂度问题，进而明确了设计方案的目标，就可以开展架构设计流程第 2 步——设计备选方案。架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。1. 几种常见的架构设计误区**（1）**设计最优秀的方案。不要面向“简历”进行架构设计，而是要根据“合适”、“简单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。**（2）**只做一个方案。一个方案容易陷入

读写分离原理将数据库的读写操作分散到不同的节点上。读写分离需要注意的是主从复制延迟和分配机制。

读写分离只是分散了数据库读写操作的压力，但没有分餐存储压力。当数据量达到千万条甚至更多时，单台数据库服务器存储能力会成为瓶颈。主要体现为一下几个方面：业务分库存在三个问题。1） Join操作。业务分库后，原本在同一数据库的表分散到不同的数据库中，导致无法使用Join查询。2）事务问题原本在同一数据库中不同的表可以在同一事务中修改，分库后，表分开，无法通过事务统一修改。3）成本问题本来一个服务器可以搞定的事情，需要拆分成三个服务器，成本提高。水平分表后需要考虑（1）路由（2）

低成本**What：**低成本是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。**How：**一般通过“创新”达到低成本的目标。（1）引入新技术。主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合；一般中小型公司基本采用该方式达到目标。（2）开创一个全新技术领域。主要复杂度在于需要去创造全新的理念和技术，并且与旧技术相比，需要有质的飞跃，复杂度更高；一般大公司拥有更多的资源、技术实力会采用该方式来

规模带来复杂度主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有：功能越来越多，导致系统复杂度指数级上升例如，某个系统开始只有 3 大功能，后来不断增加到 8 大功能，虽然还是同一个系统，但复杂度已经相差很大了，具体相差多大呢？我以一个简单的抽象模型来计算一下，假设系统间的功能都是两两相关的，系统的复杂度 = 功能数量 + 功能之间的连接数量，通过计算我们可以看出：3 个功能的系统复杂度 = 3 + 3 = 68 个功能的系统复杂度 = 8

What：什么是架构的可扩展性？业务需求、运行环境方面的变化都会导致软件系统发生变化，而这种软件系统对上述变化的适应能力就是可扩展性。可扩展性可以理解为是一种从功能需求方面考虑的软件属性，属性就会存在好坏之分。按照可扩展性的定义，一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开放，对修改关闭。衡量一个软件系统具备良好可扩展性主要表现但不限于：（1）软件自身内部方面。在软件系统实现新增的业务功能时，对现有系统功能影响较少，即不需要对现有功能作任何改动或者很少改动。（2）软件外部方面。软件系

HOW - 如何做到高可用核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，

WHY - 为什么会出现不可用？硬件故障。网站多运行在普通的商用服务器，而这些服务器本身就不具备高可用性，再加之网站系统背后有数量众多服务器，那么一定时间内服务器宕机是大概率事件，直接导致部署在该服务器上的服务受影响。软件BUG或网站更新升级发布。BUG不能消灭，只能减少；上线后的系统在运行过程中，难免会出现故障，而这些故障同样直接导致某些网站服务不可用；此外，网站更新升级发布也会引起相对较频繁的服务器宕机。不可抗拒力。如地震、水灾、战争等。...

高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。支付宝业务，对于可用性和性能就会有很高的要求，在可用性方面希望能提供7＊24不间断服务，在高性能方面则希望能实时收付款；而对于一个学生管理系统，在可用性与性能方面就不一定要有多高的要求，比如晚上可关机，几秒内能查询到信息也可接受。为此，高可用性与高性能的复杂度讨论需要结合业务需求。1 WHAT - 什么是可用性？定义可用性，可以先定义什么是不可用

什么是架构架构是为了应对软件系统复杂度而提出的一个解决方案。个人感悟是:架构即(重要)决策，是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人，财，物，时间，事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。1 架构是为了应对软件系统复杂度而提出的一个解决方案。2 架构即(重要)决策3 需求驱动架构，架起分析与设计实现的桥梁4 架构与开发成本的关系...

面试官: 小伙子，说下进程和线程？我:1， 早期的计算机是没有操作系统的，只有输入，计算，输出。手工输入速度远低于计算机的计算速度。2， 于是出现了批处理操作系统，通过纸带，磁带等工具预先写入指令，形成一个指令清单（即任务）交给计算机处理。但批处理系统的缺点是只能有一个任务，而且当计算机在进行I/O处理时，CPU是空闲的。3， 世人发明了进程，一个进程就代表一个任务，多个进程通过分时操作能让用户认为并行操作多任务，进程间的资源是独立单元，但是可以通过介质进行通信。缺点：进程内只进行串行处理

HOW 如何做好高性能？可以从垂直与水平两个维度来考虑。垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升；水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。垂直维度可包括以下措施：增大内存减少I/O操作更换为固态硬盘（SSD）提升I/O访问速度使用RAID增加I/O吞吐能力置换服务器获得更多的处理器或分配更多的虚拟核升级网络接口或增加网络接口水平维度可包括以下措施：功能分解：基于功能将系统分解为更小的子系统多实例副本：同一组件重复部署到多台不同的服

**1 WHAT 对高性能的理解?**性能是软件的一个重要质量属性。衡量软件性能包括了响应时间、TPS、服务器资源利用率等客观指标，也可以是用户的主观感受（从程序员、业务用户、终端用户/客户不同的视角，可能会得出不同的结论）。在说性能的时候，有一个概念与之紧密相关—伸缩性，这是两个有区别的概念。性能更多的是衡量软件系统处理一个请求或执行一个任务需要耗费的时间长短；而伸缩性则更加关注软件系统在不影响用户体验的前提下，能够随着请求数量或执行任务数量的增加（减少）而相应地拥有相适应的处理能力。

通过最小化预测值和真实值之间的RSS（残差平方和，多元线性回归的损失函数）来求解参数的方法时最小二乘法。

当真是标签知道时用：互信息分和V-messure 来衡量聚类效果。此种情况很少见。