上期咱们约请腾讯互娱研制部高档工程师韩伟给咱们同享了关于散布式体系的一些基础知识，了解了散布式体系发生的布景以及它是怎么进步体系承载量的。回忆往期请看《散布式体系，你真的了解吗?》

今日咱们将持续跟从韩伟的同享，来进一步学习处理散布式体系可办理性有哪些根本手法。

韩伟现就职于腾讯互娱研制部，在公共技能研制中心担任产品的架构规划和开发。多年来一向从事技能开发，拿手开发高功用体系，关于软件架构规划也有丰厚的经历。曾任网易无线事业部技能总监。

处理散布式体系可办理性的根本手法

目录服务(ZooKeeper)

散布式体系是一个由许多进程组成的全体，这个全体中每个成员部分，都会具有一些状况，比方自己的担任模块，自己的负载状况，对某些数据的把握等等。而这些和其他进程相关的数据，在毛病康复、扩容缩容的时分变得十分重要。

简略的散布式体系，能够经过静态的装备文件，来记载这些数据：进程之间的衔接对应联系，他们的IP地址和端口，等等。可是一个主动化程度高的散布式体系，必定要求这些状况数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的作业。

一些程序员会专门自己编写一个DIR服务(目录服务)，来记载集群中进程的运转状况。集群中进程会和这个DIR服务发生主动相关，这样在容灾、扩容、负载均衡的时分，就能够主动依据这些DIR服务里的数据，来调整恳求的发送目地，然后抵达绕开毛病机器、或衔接到新的服务器的操作。

可是，假如咱们仅仅用一个进程来充任这个作业。那么这个进程就成为了这个集群的“单点”——意思便是，假如这个进程毛病了，那么整个集群或许都无法运转的。所以寄存集群状况的目录服务，也需求是散布式的。幸亏咱们有ZooKeeper这个优异的开源软件，它正是一个散布式的目录服务区。

ZooKeeper能够简略发动奇数个进程，来构成一个小的目录服务集群。这个集群会供给给一切其他进程，进行读写其巨大的“装备树”的才能。这些数据不仅仅会寄存在一个ZooKeeper进程中，而是会依据一套十分安全的算法，让多个进程来承载。这让ZooKeeper成为一个优异的散布式数据保存体系。

因为ZooKeeper的数据存储结构，是一个相似文件目录的树状体系，所以咱们常常会利用它的功用，把每个进程都绑定到其间一个“分枝”上，然后经过检查这些“分支”，来进行服务器恳求的转发，就能简略的处理恳求路由(由谁去做)的问题。别的还能够在这些“分支”上符号进程的负载的状况，这样负载均衡也很简略做了。

目录服务是散布式体系中最要害的组件之一。而ZooKeeper是一个很好的开源软件，正好是用来完结这个使命。

音讯行列服务(ActiveMQ、ZeroMQ、Jgroups)

两个进程间假如要跨机器通讯，咱们简直都会用TCP/UDP这些协议。可是直接运用网络API去编写跨进程通讯，是一件十分费事的作业。除了要编写许多的底层socket代码外，咱们还要处理比方：怎么找到要交互数据的进程，怎么保证数据包的完好性不至于丢掉，假如通讯的对方进程挂掉了，或许进程需求重启应该怎样等等这一系列问题。这些问题包含了容灾扩容、负载均衡等一系列的需求。

为了处理散布式体系进程间通讯的问题，人们总结出了一个有用的模型，便是“音讯行列”模型。音讯行列模型，便是把进程间的交互，笼统成对一个个音讯的处理，而关于这些音讯，咱们都有一些“行列”，也便是管道，来对音讯进行暂存。每个进程都能够拜访一个或许多个行列，从里边读取音讯(消费)或写入音讯(出产)。因为有一个缓存的管道，咱们能够定心的对进程状况进行改变。当进程起来的时分，它会主动去消费音讯就能够了。而音讯自身的路由，也是由寄存的行列决议的，这样就把杂乱的路由问题，变成了怎么办理静态的行列的问题。

一般的音讯行列服务，都是供给简略的“投递”和“收取”两个接口，可是音讯行列自身的办理方法却比较杂乱，一般来说有两种。一部分的音讯行列服务，发起点对点的行列办理方法：每对通讯节点之间，都有一个独自的音讯行列。这种做法的优点是不同来历的音讯，能够互不影响，不会因为某个行列的音讯过多，挤占了其他行列的音讯缓存空间。而且处理音讯的程序也能够自己来界说处理的优先级——先收取、多处理某个行列，而少处理别的一些行列。

可是这种点对点的音讯行列，会跟着集群的添加而添加许多的行列，这关于内存占用和运维办理都是一个杂乱的作业。因而更高档的音讯行列服务，开端能够让不同的行列同享内存空间，而音讯行列的地址信息、树立和删去，都选用主动化的手法。——这些主动化往往需求依靠上文所述的“目录服务”，来挂号行列的ID对应的物理IP和端口等信息。比方许多开发者运用ZooKeeper来充任音讯行列服务的中心节点;而相似Jgropus这类软件，则自己保护一个集群状况来寄存各节点今昔。

别的一种音讯行列，则相似一个公共的邮箱。一个音讯行列服务便是一个进程，任何运用者都能够投递或收取这个进程中的音讯。这样关于音讯行列的运用更简洁，运维办理也比较便利。不过这种用法下，任何一个音讯从宣布到处理，最少进过两次进程间通讯，其推迟是相比照较高的。而且因为没有预订的投递、收取束缚，所以也比较简略出BUG。

不论运用那种音讯行列服务，在一个散布式服务器端体系中，进程间通讯都是必需求处理的问题，所以作为服务器端程序员，在编写散布式体系代码的时分，运用的最多的便是依据音讯行列驱动的代码，这也直接导致了EJB3.0把“音讯驱动的Bean”参加到标准之中。

事务体系

在散布式的体系中，事务是最难处理的技能问题之一。因为一个处理或许散布在不同的处理进程上，任何一个进程都或许呈现毛病，而这个毛病问题则需求导致一次回滚。这种回滚大部分又触及多个其他的进程。这是一个分散性的多进程通讯问题。要在散布式体系上处理事务问题，有必要具有两个中心东西：一个是安稳的状况存储体系;别的一个是便利牢靠的播送体系。

事务中任何一步的状况，都有必要在整个集群中可见，而且还要有容灾的才能。这个需求，一般仍是由集群的“目录服务”来承当。假如咱们的目录服务满足强健，那么咱们能够把每步事务的处理状况，都同步写到目录服务上去。ZooKeeper再次在这个地方能发挥重要的效果。

假如事务发生了中止，需求回滚，那么这个进程会触及到多个现已履行过的过程。或许这个回滚只需求在入口处回滚即可(参加那里有保存回滚所需的数据)，也或许需求在各个处理节点上回滚。假如是后者，那么就需求集群中呈现异常的节点，向其他一切相关的节点播送一个“回滚!事务ID是XXXX”这样的音讯。这个播送的底层一般会由音讯行列服务来承载，而相似Jgroups这样的软件，直接供给了播送服务。

虽然现在咱们在评论事务体系，但实际上散布式体系常常所需的“散布式锁”功用，也是这个体系能够一起完结的。所谓的“散布式锁”，也便是一种能让各个节点先检查后履行的约束条件。假如咱们有高效而单子操作的目录服务，那么这个锁状况实际上便是一种“单步事务”的状况记载，而回滚操作则默许是“暂停操作，稍后再试”。这种“锁”的方法，比事务的处理更简略，因而牢靠性更高，所以现在越来越多的开发人员，乐意运用这种“锁”服务，而不是去完成一个“事务体系”。

主动布置东西(Docker)

因为散布式体系***的需求，是在运转时(有或许需求中止服务)来进行服务容量的改变：扩容或许缩容。而在散布式体系中某些节点毛病的时分，也需求新的节点来康复作业。这些假如仍是像旧式的服务器办理方法，经过填表、申报、进机房、装服务器、布置软件……这一套做法，那功率肯定是不可。

在散布式体系的环境下，咱们一般都是选用“池”的方法来办理服务。咱们预先会请求一批机器，然后在某些机器上运转服务软件，别的一些则作为备份。明显咱们这一批服务器不或许只为某一个事务服务，而是会供给多个不同的事务承载。那些备份的服务器，则会成为多个事务的通用备份“池”。跟着事务需求的改变，一些服务器或许“退出”A服务而“参加”B服务。

这种频频的服务改变，依靠高度主动的软件布置东西。咱们的运维人员，应该把握这开发人员供给的布置东西，而不是厚厚的手册，来进行这类运维操作。一些比较有经历的开发团队，会一致一切的事务底层结构，以期大部分的布置、装备东西，都能用一套通用的体系来进行办理。而开源界，也有相似的测验，最广为人知的莫过于RPM安装包格局，可是RPM的打包方法仍是太杂乱，不太契合服务器端程序的布置需求。所以后来又呈现了Chef为代表的，可编程的通用布置体系。

在虚拟机技能呈现之后，PaaS渠道为主动布置供给了强壮的支撑：假如咱们是按某个PaaS渠道的标准来编写的运用，能够彻底把程序丢给渠道去布置，其承载量核算、布置规划，都主动完结了。这方面的佼佼者是Google的AppEngine：咱们能够直接用Eclipse开发一个本地的Web运用，然后上传到AppEngine里边，一切的布置就完结了!AppEngine会主动的依据对这个Web运用的拜访量，来进行扩容、缩容、毛病康复。

可是，真实有革命性的东西，是Docker的呈现。虽然虚拟机、沙箱技能早就不是什么新技能，可是真实运用这些技能来作为布置东西的时刻却不长。Linux高效的轻量级容器技能，供给了布置上巨大的便利性——咱们能够在各种库、各种协作软件的环境下打包咱们的运用程序，然后随意的布置在任何一个Linux体系上。

为了办理许多的散布式服务器端进程，咱们的确需求花许多功夫，其优化其布置办理的作业。一致服务器端进程的运转标准，是完成主动化布置办理的根本条件。咱们能够依据“操作体系”作为标准，选用Docker技能;也能够依据“Web运用”作为标准，选用某些PaaS渠道技能;或许自己界说一些更详细的标准，自己开发完好的散布式核算渠道。

日志服务(log4j)

服务器端的日志，一向是一个既重要又简略被忽视的问题。许多团队在刚开端的时分，仅仅把日志视为开发调试、扫除BUG的辅助东西。可是很快会发现，在服务运营起来之后，日志简直是服务器端体系，在运转时能够用来了解程序状况的仅有有用手法。

虽然咱们有各种profile东西，可是这些东西大部分都不适合在正式运营的服务上敞开，因为会严峻下降其运转功用。所以咱们更多的时分需求依据日志来剖析。虽然日志从本质上，便是一行行的文本信息，可是因为其具有很大的灵活性，所以会很受开发和运维人员的注重。

日志自身从概念上，是一个很含糊的东西。你能够随意翻开一个文件，然后写入一些信息。可是现代的服务器体系，一般都会对日志做一些标准化的需求标准：

日志有必要是一行一行的，这样比较便利日后的计算剖析;每行日志文本，都应该有一些一致的头部，比方日期时刻便是根本的需求;

日志的输出应该是分等级的，比方fatal/error/warning/info/debug/trace等等，程序能够在运转时调整输出的等级，以便能够节约日志打印的耗费;日

志的头部一般还需求一些相似用户ID或许IP地址之类的头信息，用于快速查找定位过滤某一批日志记载，或许有一些其他的用于过滤缩小日志检查规模的字段，这叫做染色功用;日志文件还需求有“回滚”功用，也便是坚持固定巨细的多个文件，防止长时刻运转后，把硬盘写满。

因为有上述的各种需求，所以开源界供给了许多游戏的日志组件库，比方大名鼎鼎的log4j，以及成员很多的log4X宗族库，这些都是运用广泛而饱尝好评的东西。

不过比照日志的打印功用，日志的收集和计算功用却往往比较简略被忽视。作为散布式体系的程序员，肯定是期望能从一个会集节点，能收集计算到整个集群日志状况。而有一些日志的计算成果，乃至期望能在很短时刻内重复获取，用来监控整个集群的健康状况。

要做到这一点，就有必要有一个散布式的文件体系，用来寄存连绵不断抵达的日志(这些日志往往经过UDP协议发送过来)。而在这个文件体系上，则需求有一个相似Map Reduce架构的计算体系，这样才能对海量的日志信息，进行快速的计算以及报警。有一些开发者会直接运用Hadoop体系，有一些则用Kafka来作为日志存储体系，上面再树立自己的计算程序。

日志服务是散布式运维的仪表盘、潜望镜。假如没有一个牢靠的日志服务，整个体系的运转状况或许会是失控的。所以不管你的散布式体系节点是多仍是少，有必要花费重要的精力和专门的开发时刻，去树立一个对日志进行主动化计算剖析的体系。