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

成本 当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标， 但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。 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

内存分析工具MAT

MAT的下载地址：https://eclipse.org/mat/downloads.php 两种使用方式： 独立使用 eclipse自带MAT也可以使用 Shallow heap Shallow size就是对象本身占用内存的大小，不包含其引用的对象。 常规对象（非数组）的Shallow size有其成员变量的数量和类型决定。 数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定 因为不像c++的对象本身可以存放大量内存，java的对象成员都是些引用。 真正的内存都在堆上，看起来是一堆原生的byte[], char[],...

2017, Sep 11   —  1 minute read

故障假设与故障检测器 Election algorithm

要点 熟悉故障检测器有助于了解分布式系统中故障的本质 如何判断进程何时已经崩溃 首先，为了便于理解及阐述，做如下假设： 每对进程都通过可靠的通讯连接（尽管底层网络组件可能出现故障，但进程使用能屏蔽故障的可靠通讯协议）。 进程故障不隐含对其他进程的通信能力的威胁（没有进程依赖于其他进程来转发消息）。 进程只在崩溃时出的故障（这个假定对与很多系统来说足够来） WARNING: 一个可靠的通讯连接最终将消息传递到接收者的输入缓存区。在同步系统中，假设在必要的地方有硬件冗余，一遍底层出故障的时候，可靠通道不仅最终传递每个消息，而且是在指定时间内完成传递工作。 .名词诠释 [width=”100%”,options=”header,footer”] |==================== |中文|英文|定义 |网络分区|network partition|每个网络内的进程可以通信，但两对进程在路由故障的时候不可能通讯...

2017, Sep 09   —  1 minute read

选举算法 Election algorithm

选择一个唯一的进程来扮演特定的角色的算法成为选举算法。 举例”中央服务器”互斥算法一个变种，从临界区的进程中选择一个进程作为”服务器”。这就需要选举算法来选举一个进程。基本要求是所有进程都同意，当进程不再相担任这个角色，需要重新选举。 .名词解释 [width=”100%”,options=”header,footer”] |==================== | 中文 | 英文 | | 召集选举 | call the...

2017, Sep 09   —  1 minute read

分布式互斥

要点 临界区问题 解决分布式互斥问题的解决方案：基于消息传送的解决方案 这种解决方案独立于特定的资源管理方案，下面会具体描述其算法 部分算法后在还会进一步描述 [NOTE] 有些应用场景是没有服务器的，且需要协调它们（一对进程）对共享资源的访问。这种情况经常出现在以太网、”自组织”模式的IEEE 802.11 无线网等网络中，其中网络接口作为对等成分进行协作，使得在共享介质上一次只有一个节点进行传输。 [NOTE] 简单的解决方案是这些进程只要通过互相通信就能互斥，就能不需要服务器。 NFS文件服务器是无状态的，因此不支持文件加锁 UNIX系统提供由locked（守护进程）实现的一个文件加锁服务。 互斥算法 假设：...

2017, Apr 05   —  2 minute read