架构设计流程

识别复杂度 将主要的复杂度问题列出来， 然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题 对于按照复杂度优先级解决的方式，存在一个普遍的担忧：如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。 这个担忧理论上是可能的，但现实中几乎是不可能出现的，原因在于软件系统的可塑性和易变性。 对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。 即使决定要推倒重来，这个新的方案也必须能够同时解决已经被解决的复杂度问题， 一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。 例如：Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。 关键指标 “高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。 对于常见中间件的性能量级范围： nginx负载均衡性能是3万左右，mc的读取性能5万左右，kafka号称百万级， zookeeper写入读取2万以上，http请求访问大概在2万左右。...

2018, Aug 16   —  1 minute read

移动IP

当移动主机在”主站点”中连接到互联网时，数据包会以正常的方式路由到主机上； 当移动主机在其他地方连入互联网时，有两个代理进程负责重新路由，主代理（HA）和副代理（FA）。这些进程运行在主站点以及移动主机当前所在位置处的固定计算机上。 HA负责保存移动主机当前位置（即可到达移动主机的IP地址）的最新情况。 当一个移动主机离开主站点时，它会告知HA，HA会注意到该移动主机离开。 当主机离开时，HA就充当一个代理服务器。HA会通知本地路由器取消与移动主机IP地址有关的任何缓存。 当HA作为一个代理服务器时，HA会响应有关移动主机IP地址的ARP请求，将自己的局域网地址作为移动主机的网络地址发给该请求。 当移动主机到达一个新站点的时候，他会通知在此站点上的FA。FA给它分配一个”转交”地址——一个本地子网上的新的临时IP地址。 此时FA与HA联系，将移动主机的主IP地址以及分配给它的转交地址告知HA。 HA将转交地址发送给原来的发送者.发送者如果支持移动IP会用这个新地址与移动主机通信.

2018, Jul 31   —  1 minute read

分布式系统中的路由算法

“图”的最短路径问题，路由是其一个实例。 === 路由算法 决定数据包传输到目的地址的路由是由路由算法负责的——它由每个节点的一个网络层程序实现。 活动： 必须决定数据包传递时的路径 电路交换网络层（如X.25）和帧中继网络（如ATM），一旦建立虚拟电路或连接，路由就确定来。 在包交换层（如IP）中，数据包的路由是单独指定的。 此算法必须简单有效 必须通过监控流量和检测配置变化或故障来动态地更新网络的知识（开销信息、建立和维护路由表） 计算量大 时间可以慢 路由是一段一段决定的：用本地信息决定下一步怎么走，本地信息依靠一个分发链路状态信息（负载和故障状态）的算法定期更新。 ==== 距离向量算法（distance...

2018, Jun 04   —  1 minute read

分布式系统网络互联的几个议题

性能 延迟：执行操作之后和到达计算机之前的这段时间。 数据传输率：一旦传输过程开始，数据在网络上两台计算机之间的传输速度，bit/s 传输时间= 延迟 + 传输距离/数据传输率 —- 举例：一个客户将200字节的请求消息发送到一个服务，服务产生了5000字节的应答。 1> 使用TCP 2> 使用UDP 3> 客户和服务器在一个主机上...

2018, Mar 26   —  1 minute read

复杂度中的低成本、安全、规模

成本 当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标， 但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。 2013年5月17日，阿里集团最后一台IBM小机在支付宝下线。 这是自2009年“去IOE”战略透露以来，“去IOE”非常重要的一个节点。 “去IOE”指的是摆脱掉IT部署中原有的IBM小型机、Oracle数据库以及EMC存储的过度依赖。 告别最后一台小机，意味着整个阿里集团尽管还有一些Oracle数据库和EMC存储，但是IBM小型机已全部消失。 7月10日，淘宝重中之重的广告系统使用的Oracle数据库下线，也是整个淘宝最后一个Oracle数据库。 这两件事合在一起是阿里巴巴技术发展过程中的一个重要里程碑 通过一个架构方案的设计，就能轻松节约几千万元，不但展现了技术的强大力量，也带来了可观的收益， 对于技术人员来说，最有满足感的事情莫过于如此了。 当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求； 而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标。 “低成本”本身与”高性能”、”高可用”是冲突的。所以低成本将作为框架的附加约束，而不是首要目标。 低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标。...

2017, Dec 02   —  1 minute read

复杂度中的可扩展性

可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时， 系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。 设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化。 预测变化 软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现。 “唯一不变的是变化”，如果按照这个标准去衡量，架构师每个设计方案都要考虑可扩展性。例如，架构师准备设计一个简单的后台管理系统，当架构师考虑用 MySQL 存储数据时，是否要考虑后续需要用 Oracle 来存储？当架构师设计用 HTTP 做接口协议时，是否要考虑要不要支持 ProtocolBuffer？甚至更离谱一点，架构师是否要考虑 VR 技术对架构的影响从而提前做好可扩展性？如果每个点都考虑可扩展性，架构师会不堪重负，架构设计也会异常庞大且最终无法落地。但架构师也不能完全不做预测，否则可能系统刚上线，马上来新的需求就需要重构，这同样意味着前期很多投入的工作量也白费了。...

2017, Dec 01   —  1 minute read

复杂度中的可用性

维基百科是这么定义可用性的：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。 CAP定理中，A的定义：每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 简单讲就是有去必回！ 但从实际情况来说，无论是单个硬件或软件都不可能做到无中断。而且除了软件和硬件本身，外界的因素也会导致中断。 既然是这样，那怎么最大限度避免呢？ 做”冗余”！单节点容易出问题，就做冗余多节点。地区网络容易出问题，就”异地多活”。 高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。 通过”冗余”增强了可用性，但也同时带来复杂性。 计算高可用 这里的“计算”指的是业务的逻辑处理。 计算有一个特点就是无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的，所以将计算从一台机器迁移到另外一台机器，对业务并没有什么影响。 随着性能的提升，单节点变为多节点集群，具有以下表现： 需要增加一个任务分配器，选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面因素。 任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。 任务分配器需要增加分配算法。例如，常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。...

2017, Nov 30   —  1 minute read

架构复杂度中的性能

性能带来的复杂度主要体现在两方面： 单台计算机内部为了获得高性能而带来的复杂度。 另一方面是多台计算机集群为了获得高性能而带来的复杂度。 此处的单台计算机并非都可以用集群中的单节点来涵盖。 伸缩性和高性能息息相关的 单机 计算机内部复杂度最关键的地方就是操作系统，是作为将硬件性能充分发挥出来的关键。 操作系统作为软件的运行环境，其复杂度直接决定了软件系统的复杂度。 操作系统和性能最相关的就是进程和线程。 在早期，计算机一次只能执行一个任务，如果某个任务需要从 I/O 设备（例如磁带）读取大量的数据，在 I/O 操作的过程中，CPU 其实是空闲的，而这个空闲时间本来是可以进行其他计算的。...

2017, Nov 29   —  1 minute read