学习一个知识之前，我觉得比较好的方式是先理解它的来龙去脉：即这个知识产生的过程，它解决了什么问题，它是怎么样解决的，还有它引入了哪些新的问题（没有银弹），这样我们才能比较好的抓到它的脉络和关键点，不会一开始就迷失在细节中。

所以，在学习分布式系统之前，我们需要解决的第一个问题是：分布式系统解决了什么问题？

分布式系统解决了什么问题？

第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太大高，一般的公司很难承受；

第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案；

第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

基于上面的三个原因可以看出，在互联网时代，单机系统是无法解决成本和高可用问题的，但是这两个问题对几乎对所有的公司来说都是非常关键的问题，所以，从单机系统到分布式系统是无法避免的技术大潮流。

分布式系统是怎么来解决问题的？

那么，分布式系统是怎么来解决单机系统面临的成本和高可用问题呢？

其实思路很简单，就是将一些廉价的 PC 机通过网络连接起来，共同完成工作，并且在系统中提供冗余来解决高可用的问题。

分布式系统引入了哪些新的问题？

我们来看分布式系统的定义：分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。在定义中，我们可用看出，分布式系统它通过多工作节点来解决单机系统面临的成本和可用性问题，但是它引入了对分布式系统内部工作节点的协调问题。

我们经常说掌握一个知识需要理解它的前因后果，对于分布式系统来说，前因是「分布式系统解决了什么问题」，后果是「它是怎么做内部工作节点的协调」，所以我们要解决的第二个问题是：分布式系统是怎么做内部工作节点协调的？

分布式计算引入了哪些新的问题？

先从简单的情况入手，对于分布式计算（无状态）的情况，系统内部的协调需要做哪些工作：

1.怎么样找到服务？

在分布式系统内部，会有不同的服务（角色），服务 A 怎么找到服务 B 是需要解决的问题，一般来说服务注册与发现机制是常用的思路，所以可以了解一下服务注册发现机制实现原理，并且可以思考服务注册发现是选择做成 AP 还是 CP 系统更合理（严格按 CAP 理论说，我们目前使用的大部分系统很难满足 C 或者 A 的，所以这里只是通常意义上的 AP 或者 CP）；

2.怎么样找到实例？

找到服务后，当前的请求应该选择发往服务的哪一个实例呢？一般来说，如果同一个服务的实例都是完全对等的（无状态），那么按负载均衡策略来处理就足够（轮询、权重、hash、一致性 hash，fair 等各种策略的适用场景）；如果同一个服务的实例不是对等的（有状态），那么需要通过路由服务（元数据服务等）先确定当前要访问的请求数据做哪一个实例上，然后再进行访问。

3.怎么样避免雪崩？

系统雪崩是指故障的由于正反馈循序导致不断扩大规则的故障。一次雪崩通常是由于整个系统中一个很小的部分出现故障于引发，进而导致系统其它部分也出现故障。比如系统中某一个服务的一个实例出现故障，导致负载均衡将该实例摘除而引起其它实例负载升高，最终导致该服务的所有实例像多米诺骨牌一样一个一个全部出现故障。

避免雪崩总体的策略比较简单，只要是两个思路，一个是快速失败和降级机制（熔断、降级、限流等），通过快速减少系统负载来避免雪崩的发生；另一个为弹性扩容机制，通过快速增加系统的服务能力来避免雪崩的发生。这个根据不同的场景可以做不同的选择，或者两个策略都使用。

一般来说，快速失败会导致部分的请求失败，如果分布式系统内部对一致性要求很高的话，快速失败会带来系统数据不一致的问题，弹性扩容会是一个比较好的选择，但是弹性扩容的实现成本和响应时间比快速失败要大得多。

4.怎么样监控告警？

对于一个分布式系统，如果我们不能很清楚地了解内部的状态，那么高可用是没有办法完全保障的，所以对分布式系统的监控（比如接口的时延和可用性等信息），分布式追踪 Trace，模拟故障的混沌工程，以及相关的告警等机制是一定要完善的；

分布式存储引入了哪些新的问题？

接下来我们再来看分布式存储（有状态）的内部的协调是怎么做的，同时，前面介绍的分布式计算的协调方式在分布式存储中同样适用，就不再重复了：

1.分布式系统的理论与衡权

ACID、BASE 和 CAP 理论，了解这三个主题，推荐这一篇文章以及文章后面相关的参考文献：

英文版本：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

中文版本：https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed/

2.怎么样做数据分片？

单机的存储能力是不可能存储所有的数据的，所以需要解决怎么将数据按一定的规则分别存储到不同的机器上，目前使用比较多的方案为：Hash、Consistent Hash 和 Range Based 分片策略，可以了解一下它们的优缺点和各自的应用场景；

3.怎么样做数据复制？

为什么满足系统的高可用要求，需要对数据做冗余处理，目前的方案主要为：中心化方案（主从复制、一致性协议比如 Raft 和 Paxos 等）和 去中心化的方案（Quorum 和 Vector Clock）了解一下它们的优缺点和各自的应用场景，以及对系统外部表现出来的数据一致性级别（线性一致性、顺序一致性、最终一致性等）；

4.怎么样做分布式事务？

对于分布式系统来说，要实现事务，首先需要有对并发事务进行排序的能力，这样在事务冲突的时候，确认哪个事务提供成功，哪个事务提交失败。对于单机系统来说这个完全不是问题，简单通过时间戳加序号的方式就可以实现，但是对于分布式系统来说，系统中机器的时间不能完全同步，并且单台机器序号也没用全局意义，按上面的方式说行不通的。不过整个系统选一台机器按单机的模式生产事务 ID 是可以的，同城多中心和短距离的异地多中心都没有问题，不过想做成全球分布式系统的话，那么每一次事务都要去一个节点去获取事务 ID 的成本太高（比如中国杭州到美国东部的 RTT 为 200 + ms ），Google 的 Spanner 是通过 GPS 和原子钟实现 TrueTime API 来解决这个问题从而实现全球分布式数据库的。

有了事务 ID 后，通过 2PC 或者 3PC 协议来实现分布式事务的原子性，其他部分和单机事务差别不大，就不再细说来。

进阶学习阶段

到这里，对分布式系统脉络上有了基本的概念，接下来开始进入细节学习阶段，这也是非常幸苦的阶段，对于分布式系统的理解深入与否，对细节的深入度是很重要的评价指标，毕竟魔鬼在细节。这里可以往两个方面进行系统的学习：

1.从实践出发

研究目前比较常用的分布式系统的设计，HDFS 或者 GFS（分布式文件系统）、Kafka 和 Pulsar（分布式消息队列），Redis Cluster 和 Codis（分布式缓存），MySQL 的分库分表（传统关系型数据库的分布式方案），MongoDB 的 Replica Set 和 Sharing 机制集以及去中心化的 Cassandra（NoSQL 数据库），中心化的 TiDB 和去中心化的 CockroachDB（NewSQL），以及一些微服务框架等；

2.从理论出发

从理论出发，研究分布式相关的论文，这里推荐一本书「Designing Data-Intensive Applications」（中文版本：数据密集型应用系统设计），先整体看书，对比较感兴趣的章节，再读一读该章节中涉及到的相关参考文献。

总结

本文从分布式系统解决的问题开始，再讨论它是怎么样来解决问题的，最后讨论了它引入了哪些新的问题，并且讨论这些新问题的解决办法，这个就是分布式系统大概的知识脉络。掌握这个知识脉络后，那么就可以从实践和理论两个角度结合起来深入细节研究分布式系统了。

参考

知乎 | 如何系统性的学习分布式系统

Martin Kleppmann.Designing Data-Intensive Applications

CAP Twelve Years Later: How the “Rules” Have Changed

另外，我先后创建了 Codis、TiDB。去年12月份创建了 TiKV 这个 project，TiKV 在所有的 rust 项目里目前排名前三。

首先我们聊聊 Database 的历史，在已经有这么多种数据库的背景下我们为什么要创建另外一个数据库；以及说一下现在方案遇到的困境，说一下 Google Spanner 和 F1、TiKV 和 TiDB，说一下架构的事情，在这里我们会重点聊一下 TiKV。因为我们产品的很多特性是 TiKV 提供的，比如说跨数据中心的复制、Transaction、auto-scale。

接下来聊一下为什么 TiKV 用 Raft 能实现所有这些重要的特性，以及 scale、MVCC 和事务模型。东西非常多，我今天不太可能把里面的技术细节都描述得特别细，因为几乎每一个话题都可以找到一篇或者是多篇论文，所以详细的技术问题大家可以单独来找我聊。

后面再说一下我们现在遇到的窘境，就是大家常规遇到的分布式方案有哪些问题，比如 MySQL Sharding。我们创建了无数 MySQL Proxy，比如官方的 MySQL proxy、Youtube 的 Vitess、淘宝的 Cobar、TDDL以及基于 Cobar 的 MyCAT、金山的 Kingshard、360 的 Atlas、京东的 JProxy，我在豌豆荚也写了一个。可以说，随便一个大公司都会造一个 MySQL Sharding 的方案。

为什么我们要创建另外一个数据库？

昨天晚上我还跟一个同学聊到，基于 MySQL 的方案它的天花板在哪里，它的天花板特别明显。有一个思路是能不能通过 MySQL 的 server 把 InnoDB 变成一个分布式数据库，听起来这个方案很完美，但是很快就会遇到天花板。因为 MySQL 生成的执行计划是个单机的，它认为整个计划的 cost 也是单机的，我读取一行和读取下一行之间的开销是很小的，比如迭代 next row 可以立刻拿到下一行。实际上在一个分布式系统里面，这是不一定的。

另外，你把数据都拿回来计算这个太慢了，很多时候我们需要把我们的 expression 或者计算过程等等运算推下去，向上返回一个最终的计算结果，这个一定要用分布式的 plan，前面控制执行计划的节点，它必须要理解下面是分布式的东西，才能生成最好的 plan，这样才能实现最高的执行效率。

比如说你做一个 sum，你是一条条拿回来加，还是让一堆机器一起算，最后给我一个结果。 例如我有 100 亿条数据分布在 10 台机器上，并行在这 10台机器我可能只拿到 10 个结果，如果把所有的数据每一条都拿回来，这就太慢了，完全丧失了分布式的价值。聊到 MySQL 想实现分布式，另外一个实现分布式的方案就是 Proxy。但是 Proxy 本身的天花板在那里，就是它不支持分布式的 transaction，它不支持跨节点的 join，它无法理解复杂的 plan，一个复杂的 plan 打到 Proxy 上面，Proxy 就傻了，我到底应该往哪一个节点上转发呢，如果我涉及到 subquery sql 怎么办？所以这个天花板是瞬间会到，在传统模型下面的修改，很快会达不到我们的要求。

另外一个很重要的是，MySQL 支持的复制方式是半同步或者是异步，但是半同步可以降级成异步，也就是说任何时候数据出了问题你不敢切换，因为有可能是异步复制，有一部分数据还没有同步过来，这时候切换数据就不一致了。前一阵子出现过某公司突然不能支付了这种事件，今年有很多这种类似的 case，所以微博上大家都在说“说好的异地多活呢？”……

为什么传统的方案在这上面解决起来特别的困难，天花板马上到了，基本上不可能解决这个问题。另外是多数据中心的复制和数据中心的容灾，MySQL 在这上面是做不好的。

在前面三十年基本上是关系数据库的时代，那个时代创建了很多伟大的公司，比如说 IBM、Oracle、微软也有自己的数据库，早期还有一个公司叫 Sybase，有一部分特别老的程序员同学在当年的教程里面还可以找到这些东西，但是现在基本上看不到了。

另外是 NoSQL。NoSQL 也是一度非常火，像 Cassandra、MongoDB 等等，这些都属于在互联网快速发展的时候创建这些能够 scale 的方案，但 Redis scale 出来比较晚，所以很多时候大家把 Redis 当成一个 Cache，现在慢慢大家把它当成存储不那么重要的数据的数据库。因为它有了 scale 支持以后，大家会把更多的数据放在里面。

然后到了 2015，严格来讲是到 2014 年到 2015 年之间，Raft 论文发表以后，真正的 NewSQL 的理论基础终于完成了。我觉得 NewSQL 这个理论基础，最重要的划时代的几篇论文，一个是谷歌的 Spanner，是在 2013 年初发布的；再就是 Raft 是在 2014 年上半年发布的。这几篇相当于打下了分布式数据库 NewSQL 的理论基础，这个模型是非常重要的，如果没有模型在上面是堆不起来东西的。说到现在，大家可能对于模型还是可以理解的，但是对于它的实现难度很难想象。

前面我大概提到了我们为什么需要另外一个数据库，说到 Scalability 数据的伸缩，然后我们讲到需要 SQL，比如你给我一个纯粹的 key-velue 系统的 API，比如我要查找年龄在 10 岁到 20 岁之间的 email 要满足一个什么要求的。如果只有 KV 的 API 这是会写死人的，要写很多代码，但是实际上用 SQL 写一句话就可以了，而且 SQL 的优化器对整个数据的分布是知道的，它可以很快理解你这个 SQL，然后会得到一个最优的 plan，他得到这个最优的 plan 基本上等价于一个真正理解 KV 每一步操作的人写出来的程序。通常情况下，SQL 的优化器是为了更加了解或者做出更好的选择。

另外一个就是 ACID 的事务，这是传统数据库必须要提供的基础。以前你不提供 ACID 就不能叫数据库，但是近些年大家写一个内存的 map 也可以叫自己是数据库。大家写一个 append-only 文件，我们也可以叫只读数据库，数据库的概念比以前极大的泛化了。

另外就是高可用和自动恢复，他们的概念是什么呢？有些人会有一些误解，因为今天还有朋友在现场问到，出了故障，比如说一个机房挂掉以后我应该怎么做切换，怎么操作。这个实际上相当于还是上一代的概念，还需要人去干预，这种不算是高可用。

未来的高可用一定是系统出了问题马上可以自动恢复，马上可以变成可用。比如说一个机房挂掉了，十秒钟不能支付，十秒钟之后系统自动恢复了变得可以支付，即使这个数据中心再也不起来我整个系统仍然是可以支付的。Auto-Failover 的重要性就在这里。大家不希望在睡觉的时候被一个报警给拉起来，我相信大家以后具备这样一个能力，5 分钟以内的报警不用理会，挂掉一个机房，又挂掉一个机房，这种连续报警才会理。我们内部开玩笑说，希望大家都能睡个好觉，很重要的事情就是这个。

说完应用层的事情，现在很有很多业务，在应用层自己去分片，比如说我按照 user ID在代码里面分片，还有一部分是更高级一点我会用到一致性哈希。问题在于它的复杂度，到一定程度之后我自动的分库，自动的分表，我觉得下一代数据库是不需要理解这些东西的，不需要了解什么叫做分库，不需要了解什么叫做分表，因为系统是全部自动搞定的。同时复杂度，如果一个应用不支持事务，那么在应用层去做，通常的做法是引入一个外部队列，引入大量的程序机制和状态转换，A 状态的时候允许转换到 B 状态，B 状态允许转换到 C 状态。

举一个简单的例子，比如说在京东上买东西，先下订单，支付状态之后这个商品才能出库，如果不是支付状态一定不能出库，每一步都有严格的流程。

Google Spanner / F1

说一下 Google 的 Spanner 和 F1，这是我非常喜欢的论文，也是我最近几年看过很多遍的论文。 Google Spanner 已经强大到什么程度呢？Google Spanner 是全球分布的数据库，在国内目前普遍做法叫做同城两地三中心，它们的差别是什么呢？以 Google 的数据来讲，谷歌比较高的级别是他们有 7 个副本，通常是美国保存 3 个副本，再在另外 2 个国家可以保存 2 个副本，这样的好处是万一美国两个数据中心出了问题，那整个系统还能继续可用，这个概念就是比如美国 3 个副本全挂了，整个数据都还在，这个数据安全级别比很多国家的安全级别还要高，这是 Google 目前做到的，这是全球分布的好处。

现在国内主流的做法是两地三中心，但现在基本上都不能自动切换。大家可以看到很多号称实现了两地三中心或者异地多活，但是一出现问题都说不好意思这段时间我不能提供服务了。大家无数次的见到这种 case， 我就不列举了。

Spanner 现在也提供一部分 SQL 特性。在以前，大部分 SQL 特性是在 F1 里面提供的，现在 Spanner 也在逐步丰富它的功能，Google 是全球第一个做到这个规模或者是做到这个级别的数据库。事务支持里面 Google 有点黑科技（其实也没有那么黑），就是它有GPS 时钟和原子钟。大家知道在分布式系统里面，比如说数千台机器，两个事务启动先后顺序，这个顺序怎么界定(事务外部一致性)。这个时候 Google 内部使用了 GPS 时钟和原子钟，正常情况下它会使用一个GPS 时钟的一个集群，就是说我拿的一个时间戳，并不是从一个 GPS 上来拿的时间戳，因为大家知道所有的硬件都会有误差。如果这时候我从一个上拿到的 GPS 本身有点问题，那么你拿到的这个时钟是不精确的。而 Google 它实际上是在一批 GPS 时钟上去拿了能够满足 majority 的精度，再用时间的算法，得到一个比较精确的时间。大家知道 GPS 也不太安全，因为它是美国军方的，对于 Google 来讲要实现比国家安全级别更高的数据库，而 GPS 是可能受到干扰的，因为 GPS 信号是可以调整的，这在军事用途上面很典型的，大家知道导弹的制导需要依赖 GPS，如果调整了 GPS 精度，那么导弹精度就废了。所以他们还用原子钟去校正 GPS，如果 GPS 突然跳跃了，原子钟上是可以检测到 GPS 跳跃的，这部分相对有一点黑科技，但是从原理上来讲还是比较简单，比较好理解的。

最开始它 Spanner 最大的用户就是 Google 的 Adwords，这是 Google 最赚钱的业务，Google 就是靠广告生存的，我们一直觉得 Google 是科技公司，但是他的钱是从广告那来的，所以一定程度来讲 Google 是一个广告公司。Google 内部的方向先有了 Big table ，然后有了 MegaStore ，MegaStore 的下一代是 Spanner ，F1 是在 Spanner 上面构建的。

TiDB and TiKV

TiKV 和 TiDB 基本上对应 Google Spanner 和 Google F1，用 Open Source 方式重建。目前这两个项目都开放在 GitHub 上面，两个项目都比较火爆，TiDB 是更早一点开源的， 目前 TiDB 在 GitHub 上 有 4300 多个 Star，每天都在增长。

另外，对于现在的社会来讲，我们觉得 Infrastructure 领域闭源的东西是没有任何生存机会的。没有任何一家公司，愿意把自己的身家性命压在一个闭源的项目上。举一个很典型的例子，在美国有一个数据库叫 FoundationDB，去年被苹果收购了。FoundationDB 之前和用户签的合约都是一年的合约。比如说，我给你服务周期是一年，现在我被另外一个公司收购了，我今年服务到期之后，我是满足合约的。但是其他公司再也不能找它服务了，因为它现在不叫 FoundationDB 了，它叫 Apple了，你不能找 Apple 给你提供一个 Enterprise service。

TiDB 和 TiKV 为什么是两个项目，因为它和 Google 的内部架构对比差不多是这样的：TiKV 对应的是 Spanner，TiDB 对应的是 F1 。F1 里面更强调上层的分布式的 SQL 层到底怎么做，分布式的 Plan 应该怎么做，分布式的 Plan 应该怎么去做优化。同时 TiDB 有一点做的比较好的是，它兼容了 MySQL 协议，当你出现了一个新型的数据库的时候，用户使用它是有成本的。大家都知道作为开发很讨厌的一个事情就是，我要每个语言都写一个 Driver，比如说你要支持 C++、你要支持 Java、你要支持 Go 等等，这个太累了，而且用户还得改他的程序，所以我们选择了一个更加好的东西兼容 MySQL 协议，让用户可以不用改。一会我会用一个视频来演示一下，为什么一行代码不改就可以用，用户就能体会到 TiDB 带来的所有的好处。

这个图实际上是整个协议栈或者是整个软件栈的实现。大家可以看到整个系统是高度分层的，从最底下开始是 RocksDB ，然后再上面用 Raft 构建一层可以被复制的 RocksDB ，在这一层的时候它还没有 Transaction，但是整个系统现在的状态是所有写入的数据一定要保证它复制到了足够多的副本。也就是说只要我写进来的数据一定有足够多的副本去 cover 它，这样才比较安全，在一个比较安全的 Key-value store 上面， 再去构建它的多版本，再去构建它的分布式事务，然后在分布式事务构建完成之后，就可以轻松的加上 SQL 层，再轻松的加上MySQL 协议的支持。然后，这两天我比较好奇，自己写了 MongoDB 协议的支持，然后我们可以用 MongoDB 的客户端来玩，就是说协议这一层是高度可插拔的。TiDB 上可以在上面构建一个 MongoDB 的协议，相当于这个是构建一个 SQL 的协议，可以构建一个 NoSQL 的协议。这一点主要是用来验证 TiKV 在模型上面的支持能力。

这是整个 TiKV 的架构图，从这个看来，整个集群里面有很多 Node，比如这里画了四个 Node ，分别对应了四个机器。每一个 Node 上可以有多个 Store，每个 Store 里面又会有很多小的 Region，就是说一小片数据，就是一个 Region 。从全局来看所有的数据被划分成很多小片，每个小片默认配置是 64M，它已经足够小，可以很轻松的从一个节点移到另外一个节点，Region 1 有三个副本，它分别在 Node1、Node 2 和 Node4 上面， 类似的Region 2，Region 3 也是有三个副本。每个 Region 的所有副本组成一个 Raft Group，整个系统可以看到很多这样的 Raft groups。

Raft 细节我不展开了，大家有兴趣可以找我私聊或者看一下相应的资料。

因为整个系统里面我们可以看到上一张图里面有很多 Raft group 给我们，不同 Raft group 之间的通讯都是有开销的。所以我们有一个类似于 MySQL 的 group commit 机制 ，你发消息的时候实际上可以 share 同一个 connection ， 然后 pipeline + batch 发送，很大程度上可以省掉大量 syscall 的开销。

另外，其实在一定程度上后面我们在支持压缩的时候，也有非常大的帮助，就是可以减少数据的传输。对于整个系统而言，可能有数百万的 Region，它的大小可以调整，比如说 64M、128M、256M，这个实际上依赖于整个系统里面当前的状况。

比如说我们曾经在有一个用户的机房里面做过测试，这个测试有一个香港机房和新加坡的机房。结果我们在做复制的时候，新加坡的机房大于 256M 就复制不过去，因为机房很不稳定，必须要保证数据切的足够小，这样才能复制过去。

如果一个 Region 太大以后我们会自动做 SPLIT，这是非常好玩的过程，有点像细胞的分裂。

然后 TiKV 的 Raft 实现，是从 etcd 里面 port 过来的，为什么要从 etcd 里面 port 过来呢？首先 TiKV 的 Raft 实现是用 Rust 写的。作为第一个做到生产级别的 Raft 实现，所以我们从 etcd 里面把它用 Go 语言写的 port 到这边。

这个是 Raft 官网上面列出来的 TiKV在里面的状态，大家可以看到 TiKV 把所有 Raft 的 feature 都实现了。 比如说 Leader Election、Membership Changes，这个是非常重要的，整个系统的 scale 过程高度依赖 Membership Changes，后面我用一个图来讲这个过程。后面这个是 Log Compaction，这个用户不太关心。

这是很典型的细胞分裂的图，实际上 Region 的分裂过程和这个是类似的。

我们看一下扩容是怎么做的。

比如说以现在的系统假设，我们刚开始说只有三个节点，有 Region1 分别是在 1 、2、4，我用虚线连接起来代表它是一个 Raft group ，大家可以看到整个系统里面有三个 Raft group ，在每一个 Node 上面数据的分布是比较均匀的，在这个假设每一个 Region 是 64M ，相当于只有一个 Node 上面负载比其他的稍微大一点点。

一个在线视频默认我们都是推荐 3 个副本或者 5 个副本的配置。Raft 本身有一个特点，如果一个 leader down 掉之后，其它的节点会选一个新的 leader ，那么这个新的 leader 会把它还没有 commit 但已经 reply 过去的 log 做一个 commit ，然后会再做 apply ，这个有点偏 Raft 协议，细节我不讲了。

复制数据的小的 Region，它实际上是跨多个数据中心做的复制。这里面最重要的一点是永远不丢失数据，无论如何我保证我的复制一定是复制到 majority ，任何时候我只要对外提供服务，允许外面写入数据一定要复制到 majority 。很重要的一点就是恢复的过程一定要是自动化的，我前面已经强调过，如果不能自动化恢复，那么中间的宕机时间或者对外不可服务的时间，便不是由整个系统决定的，这是相对回到了几十年前的状态。

MVCC

MVCC 我稍微仔细讲一下这一块。MVCC 的好处，它很好支持 Lock-free 的 snapshot read ，一会儿我有一个图会展示 MVCC 是怎么做的。isolation level 就不讲了， MySQL 里面的级别是可以调的，我们的 TiKV 有 SI，还有 SI+lock，默认是支持 SI 的这种隔离级别，然后你写一个 select for update 语句，这个会自动的调整到 SI 加上 lock 这个隔离级别。这个隔离级别基本上和 SSI 是一致的。还有一个就是 GC 的问题，如果你的系统里面的数据产生了很多版本，你需要把这个比较老的数据给 GC 掉，比如说正常情况下我们是不删除数据的， 你写入一行，然后再写入一行，不断去 update 同一行的时候，每一次 update 会产生新的版本，新的版本就会在系统里存在，所以我们需要一个 GC 的模块把比较老的数据给 GC 掉，实际上这个 GC 不是 Go 里面的GC，不是 Java 的 GC，而是数据的 GC。

这是一个数据版本，大家可以看到我们的数据分成两块，一个是 meta，一个是 data。meta 相对于描述我的数据当前有多少个版本。大家可以看到绿色的部分，比如说我们的 meta key 是 A ，keyA 有三个版本，是 A1 、A2、A3，我们把 key 自己和 version 拼到一起。那我们用 A1、A2、A3 分别描述 A 的三个版本，那么就是 version 1/2/3。meta 里面描述，就是我的整个 key 相对应哪个版本，我想找到那个版本。比如说我现在要读取 key A 的版本10，但显然现在版本 10 是没有的，那么小于版本 10 最大的版本是 3，所以这时我就能读取到 3，这是它的隔离级别决定的。关于 data，我刚才已经讲过了。

分布式事务模型

接下来是分布式事务模型，其实是基于 Google Percolator，这是 Google 在 2006 发表的一篇论文，是 Google 在做内部增量处理的时候发现了这个方法，本质上还是二阶段提交的。这使用的是一个乐观锁，比如说我提供一个 transaction ，我去改一个东西，改的时候是发布在本地的，并没有马上 commit 到数据存储那一端，这个模型就是说，我修改的东西我马上去 Lock 住，这个基本就是一个悲观锁。但如果到最后一刻我才提交出去，那么锁住的这一小段的时间，这个时候实现的是乐观锁。乐观锁的好处就是当你冲突很小的时候可以得到非常好的性能，因为冲突特别小，所以我本地修改通常都是有效的，所以我不需要去 Lock ，不需要去 roll back 。本质上分布式事务就是 2PC (两阶段提交) 或者是 2+x PC，基本上没有 1PC，除非你在别人的级别上做弱化。比如说我允许你读到当前最新的版本，也允许你读到前面的版本，书里面把这个叫做幻读。如果你调到这个程度是比较容易做 1PC 的，这个实际上还是依赖用户设定的隔离级别的，如果用户需要更高的隔离级别，这个 1PC就不太好做了。

这是一个路由，正常来讲，大家可能会好奇一个 SQL 语句怎么最后会落到存储层，然后能很好的运行，最后怎么能映射到 KV 上面，又怎么能路由到正确的节点，因为整个系统可能有上千个节点，你怎么能正确路由到那一个的节点。我们在 TiDB 有一个 TiKV driver ， 另外 TiKV 对外使用的是 Google Protocol Buffer 来作为通讯的编码格式。

Placement Driver

来说一下 Placement Driver 。Placement Driver 是什么呢？整个系统里面有一个节点，它会时刻知道现在整个系统的状态。比如说每个机器的负载，每个机器的容量，是否有新加的机器，新加机器的容量到底是怎么样的，是不是可以把一部分数据挪过去，是不是也是一样下线， 如果一个节点在十分钟之内无法被其他节点探测到，我认为它已经挂了，不管它实际上是不是真的挂了，但是我也认为它挂了。因为这个时候是有风险的，如果这个机器万一真的挂了，意味着你现在机器的副本数只有两个，有一部分数据的副本数只有两个。那么现在你必须马上要在系统里面重新选一台机器出来，它上面有足够的空间，让我现在只有两个副本的数据重新再做一份新的复制，系统始终维持在三个副本。整个系统里面如果机器挂掉了，副本数少了，这个时候应该会被自动发现，马上补充新的副本，这样会维持整个系统的副本数。这是很重要的 ，为了避免数据丢失，必须维持足够的副本数，因为副本数每少一个，你的风险就会再增加。这就是 Placement Driver 做的事情。

同时，Placement Driver 还会根据性能负载，不断去 move 这个 data 。比如说你这边负载已经很高了，一个磁盘假设有 100G，现在已经用了 80G，另外一个机器上也是 100G，但是他只用了 20G，所以这上面还可以有几十 G 的数据，比如 40G 的数据，你可以 move 过去，这样可以保证系统有很好的负载，不会出现一个磁盘巨忙无比，数据已经多的装不下了，另外一个上面还没有东西，这是 Placement Driver 要做的东西。

Raft 协议还提供一个很高级的特性叫 leader transfer。leader transfer 就是说在我不移动数据的时候，我把我的 leadership 给你，相当于从这个角度来讲，我把流量分给你，因为我是 leader，所以数据会到我这来，但我现在把 leader给你，我让你来当 leader，原来打给我的请求会被打给你，这样我的负载就降下来。这就可以很好的动态调整整个系统的负载，同时又不搬移数据。不搬移数据的好处就是，不会形成一个抖动。

MySQL Sharding

MySQL Sharding 我前面已经提到了它的各种天花板，MySQL Sharding 的方案很典型的就是解决基本问题以后，业务稍微复杂一点，你在 sharding 这一层根本搞不定。它永远需要一个 sharding key，你必须要告诉我的 proxy，我的数据要到哪里找，对用户来说是极不友好的，比如我现在是一个单机的，现在我要切入到一个分布式的环境，这时我必须要改我的代码，我必须要知道我这个 key ，我的 row 应该往哪里 Sharding。如果是用 ORM ，这个基本上就没法做这个事情了。有很多 ORM 它本身假设我后面只有一个 MySQL。但 TiDB 就可以很好的支持，因为我所有的角色都是对的，我不需要关注 Sharding 、分库、分表这类的事情。

这里面有一个很重要的问题没有提，我怎么做 DDL。如果这个表非常大的话，比如说我们有一百亿吧，横跨了四台机器，这个时候你要给它做一个新的 Index，就是我要添加一个新的索引，这个时候你必须要不影响任何现有的业务，实际上这是多阶段提交的算法，这个是 Google 和 F1 一起发出来那篇论文。

简单来讲是这样的，先把状态标记成 delete only ，delete only 是什么意思呢？因为在分布式系统里面，所有的系统对于 schema 的视野不是一致的，比如说我现在改了一个值，有一部分人发现这个值被改了，但是还有一部分人还没有开始访问这个，所以根本不知道它被改了。然后在一个分布系统里，你也不可能实时通知到所有人在同一时刻发现它改变了。比如说从有索引到没有索引，你不能一步切过去，因为有的人认为它有索引，所以他给它建了一个索引，但是另外一个机器他认为它没有索引，所以他就把数据给删了，索引就留在里面了。这样遇到一个问题，我通过索引找的时候告诉我有， 实际数据却没有了，这个时候一致性出了问题。比如说我 count 一个 email 等于多少的，我通过 email 建了一个索引，我认为它是在，但是 UID 再转过去的时候可能已经不存在了。

比如说我先标记成 delete only，我删除它的时候不管它现在有没有索引，我都会尝试删除索引，所以我的数据是干净的。如果我删除掉的话，我不管结果是什么样的，我尝试去删一下，可能这个索引还没 build 出来，但是我仍然删除，如果数据没有了，索引一定没有了，所以这可以很好的保持它的一致性。后面再类似于前面，先标记成 write only 这种方式，连续再迭代这个状态，就可以迭代到一个最终可以对外公开的状态。比如说当我迭代到一定程度的时候，我可以从后台 build index ，比如说我一百亿，正在操作的 index 会马上 build，但是还有很多没有 build index ，这个时候后台不断的跑 map-reduce 去 build index ，直到整个都 build 完成之后，再对外 public ，就是说我这个索引已经可用了，你可以直接拿索引来找，这个是非常经典的。在这个 Online，Asynchronous Schema Change in F1 paper之前，大家都不知道这事该怎么做。

Proxy Sharding 的方案不支持分布式事务，更不用说跨数据中心的一致性事务了。 TiKV 很好的支持 transaction，刚才提到的 Raft 除了增加副本之外，还有 leader transfer，这是一个传统的方案都无法提供的特性。以及它带来的好处，当我瞬间平衡整个系统负载的时候，对外是透明的， 做 leader transfer 的时候并不需要移动数据，只是个简单的 leader transfer 消息。

然后说一下如果大家想参与我们项目的话是怎样的过程，因为整个系统是完全开源的，如果大家想参与其中任何一部分都可以，比如说我想参与到分布式 KV，可以直接贡献到 TiKV。TiKV 需要写 Rust，如果大家对这块特别有激情可以体验写 Rust 的感觉 。

TiDB 是用 Go 写的，Go 在中国的群众基础是非常多的，目前也有很多人在贡献。整个 TiDB 和TiKV 是高度协作的项目，因为 TiDB 目前还用到了 etcd ，我们在和 CoreOS 在密切的合作，也特别感谢 CoreOS 帮我们做了很多的支持，我们也为 CoreOS 的 etcd 提了一些 patch。同时，TiKV 使用 RocksDB ，所以我们也为 RocksDB 提了一些 patch 和 test，我们也非常感谢 Facebook RocksDB team 对我们项目的支持。

另外一个是 PD，就是我们前面提的 Placement Driver，它负责监控整个系统。这部分的算法比较好玩，大家如果有兴趣的话，可以去自己控制整个集群的调度，它和 Kubernetes 或者是Mesos 的调度算法是不一样的，因为它调度的维度实际上比那个要更多。比如说磁盘的容量，你的 leader 的数量，你的网络当前的使用情况，你的 IO 的负载和 CPU 的负载都可以放进去。同时你还可以让它调度不要跨一个机房里面建多个副本。

本文来自Pivotal，分析了中国铁路总公司12306这个世界上最大的铁路系统的火车票预订系统。

在这个星球上人类最大的年度运动大概算是中国农历新年，又称春节。有3488万人次通过航空和235万人次通过铁路踏上他们的旅途。从历史上看，铁路旅行意味着排长龙队伍买票，中国铁路总公司（CRC）现在开始在网上卖火车票，提供比车站售票处或通过电话购买更方便的方法。

随着越来越多人的使用车票预订系统，12306铁路订票系统打破了其传统的RDBMS关系数据库系统，需要重新开始了一个新的项目，以改善原有系统性能和可伸缩性的问题，能够承受像春节度假旅游期间的尖峰的压力。目前该网站成为中国最受欢迎网站的之一。在这样严苛的访问条件下，系统出现以下很差用户体验：使用中断，性能差，预订错误，支付失败，票务确认出现问题等等。

中国铁道科学研究院的副主任朱剑圣首先解决性能问题，早在2011年，朱博士确保新系统解决基于下面两个性能瓶颈：

1.关系型数据库超负载，以至于不能处理传入的请求，无论是规模扩展性还是可靠性，都不能满足SLA要求的水平。 

2.UNIX服务器的计算能力不足以解决容量需求。

朱博士说：“传统关系型数据库和大型机的计算模式并不具有扩展性，系统不能基于内存扩展跨多个节点上运行。我们的网站证明了这一点，而试图扩展我们的遗留系统将变得非常昂贵”。

使用In-memory内存数据网格解决扩展性和可靠性
朱博士的团队开始寻找新的解决方案，大型机被发现和关系数据库有同样的瓶颈，在内存数据网格(IMDG)领域，他们发现了Pivotal GemFire，在海运货物系统 金融服务，航空，电子商务等多个行业都拥有成功解决最具挑战性的数据问题的良好记录。为了执行评估，朱博士和他的团队选择了国际综合系统公司（IISI）。IISI拥有强大为政府机构工作的跟踪记录，包括在开发交通运输解决方案，迁移遗留系统到云计算架构等方面经历，有与Pivotal GemFire合作经验。他们开始试点，相信了GemFire​​将满足性能，可扩展性和可用性的要求，包括能够在低成本硬件上运行。

IISI创造了一个概念证明和展示了GemFire几个优点​​。售票计算速度提高50到100倍。当负载增加时，响应时间保持10-100毫秒的延迟。他们可以看到，通过增加容量，能实现近乎线性增长的可扩展性和高可用性的能力。项目组在短短两个月内建立了一个试点，四个月后，新的在线系统全面部署，跨越5700火车站。

该小组负责铁路网上预订系统每年增长高达50％。他们的网站每天的平均水平预订250万票。

72台UNIX系统和关系数据库换成了10台初始和10个备份的x86服务器，这是一个更具成本效益的模式，能在内存中处理2TB或一个月的的火车票数据。

朱博士认为：“首先，Pivotal GemFire​​提供了一个在真实的测试环境的证明。然后，在生产环境面对意想不到的尖峰也是成功的，具体采取了一个迭代的方法来部署，克服了一系列大规模的挑战。在最近的2013春运期间，该系统具备了运行稳定的性能和正常运行时间。现在，我们有一个可靠，经济合理的生产体系​​，支持记录容量增长的空间。这个规模实现10-100毫秒的延迟。”

基于高可用性，冗余和故障切换机制上的GemFire​​提供了连续正常运行，它已超出了所有在该领域的CRC校验的指标，并帮助他们维护他们的SLA。

具体PDF下载

1. 前言

Together we will ensure that Kubernetes is a strong and open container management framework for any application and in any environment, whether in a private, public or hybrid cloud.

Urs Hölzle, Google

Kubernetes作为Docker生态圈中重要一员，是Google多年大规模容器管理技术的开源版本，是产线实践经验的最佳表现[G1] 。如Urs Hölzle所说，无论是公有云还是私有云甚至混合云，Kubernetes将作为一个为任何应用，任何环境的容器管理框架无处不在。正因为如此， 目前受到各大巨头及初创公司的青睐，如Microsoft、VMWare、Red Hat、CoreOS、Mesos等，纷纷加入给Kubernetes贡献代码。随着Kubernetes社区及各大厂商的不断改进、发展，Kuberentes将成为容器管理领域的领导者。

接下来我们会用一系列文章逐一探索Kubernetes是什么、能做什么以及怎么做。

2. 什么是Kubernetes

Kubernetes是Google开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用，其主要功能如下：

1) 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。

2) 以集群的方式运行、管理跨机器的容器。

3) 解决Docker跨机器容器之间的通讯问题。

4) Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上。

接下来本文主要从以下几方面阐述Kubernetes：

1) Kubernetes的主要概念。

2) Kubernetes的构件，包括Master组件、Kubelet、Proxy的详细介绍。

3. Kubernetes主要概念

3.1. Pods

Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod，通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion(Host)上，看作一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。

3.2. Services

Services也是Kubernetes的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。

3.3. Replication Controllers

Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods，Replication Controller根据label selector来关联，通过修改pods的label可以删除对应的pods。Replication Controller主要有如下用法：

1) Rescheduling

如上所述，Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行， 即使在节点出错时。

2) Scaling

通过修改Replication Controller的副本(replicas)数量来水平扩展或者缩小运行的pods。

3) Rolling updates

Replication Controller的设计原则使得可以一个一个地替换pods来rolling updates服务。

4) Multiple release tracks

如果需要在系统中运行multiple release的服务，Replication Controller使用labels来区分multiple release tracks。

3.4. Labels

Labels是用于区分Pod、Service、Replication Controller的key/value键值对，Pod、Service、 Replication Controller可以有多个label，但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础，为了将访问Service的请求转发给后端提供服务的多个容器，正是通过标识容器的labels来选择正确的容器。同样，Replication Controller也使用labels来管理通过pod 模板创建的一组容器，这样Replication Controller可以更加容易，方便地管理多个容器，无论有多少容器。

4. Kubernetes构件

Kubenetes整体框架如下图3-1，主要包括kubecfg、Master API Server、Kubelet、Minion(Host)以及Proxy。

图3-1 Kubernetes High Level构件

4.1. Master

Master定义了Kubernetes 集群Master/API Server的主要声明，包括Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage以及Client, 是client(Kubecfg)调用Kubernetes API，管理Kubernetes主要构件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等组成。从下图3-2可知Master的工作流主要分以下步骤：

1) Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。

2) Kubernetes Client将请求发送给API server。

3) API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。

4) REST Storage API对的请求作相应的处理。

5) 将处理的结果存入高可用键值存储系统Etcd中。

6) 在API Server响应Kubecfg的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion信息。

7) 依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod分发到可用的Minion节点上。

下面是Master的主要构件的详细介绍：

图3-2 Master主要构件及工作流

3.1.1. Minion Registry

Minion Registry负责跟踪Kubernetes 集群中有多少Minion(Host)。Kubernetes封装Minion Registry成实现Kubernetes API Server的RESTful API接口REST，通过这些API，我们可以对Minion Registry做Create、Get、List、Delete操作，由于Minon只能被创建或删除，所以不支持Update操作，并把Minion的相关配置信息存储到etcd。除此之外，Scheduler算法根据Minion的资源容量来确定是否将新建Pod分发到该Minion节点。

3.1.2. Pod Registry

Pod Registry负责跟踪Kubernetes集群中有多少Pod在运行，以及这些Pod跟Minion是如何的映射关系。将Pod Registry和Cloud Provider信息及其他相关信息封装成实现Kubernetes API Server的RESTful API接口REST。通过这些API，我们可以对Pod进行Create、Get、List、Update、Delete操作，并将Pod的信息存储到etcd中，而且可以通过Watch接口监视Pod的变化情况，比如一个Pod被新建、删除或者更新。

3.1.3. Service Registry

Service Registry负责跟踪Kubernetes集群中运行的所有服务。根据提供的Cloud Provider及Minion Registry信息把Service Registry封装成实现Kubernetes API Server需要的RESTful API接口REST。利用这些接口，我们可以对Service进行Create、Get、List、Update、Delete操作，以及监视Service变化情况的watch操作，并把Service信息存储到etcd。

3.1.4. Controller Registry

Controller Registry负责跟踪Kubernetes集群中所有的Replication Controller，Replication Controller维护着指定数量的pod 副本(replicas)拷贝，如果其中的一个容器死掉，Replication Controller会自动启动一个新的容器，如果死掉的容器恢复，其会杀死多出的容器以保证指定的拷贝不变。通过封装Controller Registry为实现Kubernetes API Server的RESTful API接口REST， 利用这些接口，我们可以对Replication Controller进行Create、Get、List、Update、Delete操作，以及监视Replication Controller变化情况的watch操作，并把Replication Controller信息存储到etcd。

3.1.5. Endpoints Registry

Endpoints Registry负责收集Service的endpoint，比如Name："mysql"，Endpoints: ["10.10.1.1:1909"，"10.10.2.2:8834"]，同Pod Registry，Controller Registry也实现了Kubernetes API Server的RESTful API接口，可以做Create、Get、List、Update、Delete以及watch操作。

3.1.6. Binding Registry

Binding包括一个需要绑定Pod的ID和Pod被绑定的Host，Scheduler写Binding Registry后，需绑定的Pod被绑定到一个host。Binding Registry也实现了Kubernetes API Server的RESTful API接口，但Binding Registry是一个write-only对象，所有只有Create操作可以使用， 否则会引起错误。

3.1.7. Scheduler

Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod，那这些资源就不能再分配给其他Pod， 除非这些Pod被删除或者退出， 因此，Kubernetes需要分析集群中所有Minion的资源使用情况，保证分发的工作负载不会超出当前该Minion节点的可用资源范围。具体来说，Scheduler做以下工作：

1) 实时监测Kubernetes集群中未分发的Pod。

2) 实时监测Kubernetes集群中所有运行的Pod，Scheduler需要根据这些Pod的资源状况安全地将未分发的Pod分发到指定的Minion节点上。

3) Scheduler也监测Minion节点信息，由于会频繁查找Minion节点，Scheduler会缓存一份最新的信息在本地。

4) 最后，Scheduler在分发Pod到指定的Minion节点后，会把Pod相关的信息Binding写回API Server。

4.2. Kubelet

图3-3 Kubernetes详细构件

根据上图3-3可知Kubelet是Kubernetes集群中每个Minion和Master API Server的连接点，Kubelet运行在每个Minion上，是Master API Server和Minion之间的桥梁，接收Master API Server分配给它的commands和work，与持久性键值存储etcd、file、server和http进行交互，读取配置信息。Kubelet的主要工作是管理Pod和容器的生命周期，其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker组件，具体工作如下：

1) 通过Worker给Pod异步运行特定的Action。

2) 设置容器的环境变量。

3) 给容器绑定Volume。

4) 给容器绑定Port。

5) 根据指定的Pod运行一个单一容器。

6) 杀死容器。

7) 给指定的Pod创建network 容器。

8) 删除Pod的所有容器。

9) 同步Pod的状态。

10) 从Cadvisor获取container info、 pod info、root info、machine info。

11) 检测Pod的容器健康状态信息。

12) 在容器中运行命令。

4.3. Proxy

Proxy是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，从上图3-3可知Proxy服务也运行在每个Minion上。Proxy提供TCP/UDP sockets的proxy，每创建一种Service，Proxy主要从etcd获取Services和Endpoints的配置信息，或者也可以从file获取，然后根据配置信息在Minion上启动一个Proxy的进程并监听相应的服务端口，当外部请求发生时，Proxy会根据Load Balancer将请求分发到后端正确的容器处理。

5. 下篇主题

下篇讲述在CentOS7上用Kubernetes来管理容器。

6. 个人简介

杨章显，现就职于Cisco，主要从事WebEx SaaS服务运维，系统性能分析等工作。特别关注云计算，自动化运维，部署等技术，尤其是Go、OpenvSwitch、Docker及其生态圈技术，如Kubernetes、Flocker等Docker相关开源项目。Email: yangzhangxian@gmail.com

7. 参考资料

1. https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs
2. http://www.slideshare.net/rajdeep
3. http://www.docker.com

感谢郭蕾对本文的策划和审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

先来个自我介绍吧！

Dubbo是什么？能做什么？

Dubbo适用于哪些场景？

Dubbo的设计思路是什么？

Dubbo的需求和依赖情况？

Dubbo的性能如何？

和淘宝HSF相比，Dubbo的特点是什么？

Dubbo在安全机制方面是如何解决的？

Dubbo在阿里巴巴内部以及外部的应用情况？

在分布式事务、多语言支持方面，Dubbo的计划是什么？

Dubbo采用的开源协议？商业应用应该注意哪些事项？

Dubbo开发团队情况？

Dubbo共有六个开发人员参与开发和测试，每一个开发人员都是很有经验，团队合作很默契，开发过程也很有节奏，有完善质量保障流程。团队组成： 

• 梁飞 （开发人员/产品管理）
• 刘昊旻 （开发人员/过程管理）
• 刘超 （开发人员/用户支持）
• 李鼎 （开发人员/用户支持）
• 陈雷 （开发人员/质量保障）
• 闾刚 （开发人员/开源运维）

 
从左至右：刘超，梁飞，闾刚，陈雷，刘昊旻，李鼎

可参见：Dubbo的团队成员

其他开发者如何参与？可以做哪些工作？

Dubbo未来的发展计划？

线下环境经常出现类似这种异常：

com.alibaba.dubbo.rpc.RpcException: Forbid consumer 10.0.53.69 access service com.kuaidadi.op.api.pay.service.PayChannelConfigRemoteService from registry 10.0.50.150:2181 use dubbo version 2.5.3, Please check registry access list (whitelist/blacklist).

public List<Invoker<T>> doList(Invocation invocation) {

 if (forbidden ) {

     throw new RpcException(RpcException.FORBIDDEN_EXCEPTION , ” Forbid consumer “ +  NetUtils. getLocalHost() + ” access service “ +        getInterface().getName() + ” from registry “ + getUrl().getAddress() + ” use dubbo version “ + Version.getVersion() + “, Please check registry access list (whitelist/blacklist).”);

}

private void refreshInvoker(List<URL> invokerUrls){

   if (invokerUrls != null && invokerUrls.size() == 1 && invokerUrls.get(0) != null && Constants.EMPTY_PROTOCOL .equals(invokerUrls.get(0).getProtocol())) {

            this.forbidden = true; // 禁止访问

            this.methodInvokerMap = null; // 置空列表

            destroyAllInvokers(); // 关闭所有Invoker

   }

意思是如果invokerUrls的size为1，并且url的协议头是Constants.EMPTY_PROTOCOL时，则设置forbidden为false，Constants.EMPTY_PROTOCOL的值是empty。

 

 

refreshInvoker方法什么时候被调用呢？当某个服务的provider有变化时就会被调用，例如zookeeper上某个服务的provider目录里的内容发生变化，则zk监听器会被触发，由于provider的数量会发生变化，例如有一个新的provider启动了，有一个provider下线了，所以必须刷新本地的对provider的连接，具体逻辑就在refreshInvoker方法里，这个方法的调用栈如下：

可以确定的是，zookeeper推送的URL的protocol部分不可能无缘无故变成了empty，肯定是由某个地方更改了，于是看一下Constants.EMPTY_PROTOCOL到底有哪些地方调用了，如下：

见图中红色圈圈部分，当zookeeper初次订阅或者订阅的信息有变更时，都会触发toUrlsChanged方法，看看这个方法内部都做了什么，完整代码如下：

     private List<URL> toUrlsWithEmpty(URL consumer, String path, List<String> providers) {

        List<URL> urls = toUrlsWithoutEmpty(consumer, providers);

        if (urls == null || urls.isEmpty()) {

           int i = path.lastIndexOf(‘/’ );

          String category = i < 0 ? path : path.substring(i + 1);

          URL empty = consumer.setProtocol(Constants.EMPTY_PROTOCOL ).addParameter(Constants. CATEGORY_KEY, category);

            urls.add(empty);

        }

        return urls;

    }

可见如果toUrlsWithoutEmpty的结果是空或者size为0，则强制返回一个protocol为empty的url，看来源头就在这里了。传入的List<String> providers实际上就是最新的服务提供者信息，当某个服务没有任何provider时，providers就变为一个size为o的List了，导致返回一个协议头为empty的url，进而导致forbidden为true，屏蔽了consumer调用。

2015年，整个IT技术领域发生了许多深刻而又复杂的变化，InfoQ策划了“解读2015”年终技术盘点系列文章，希望能够给读者清晰地梳理出技术领域在这一年的发展变化，回顾过去，继续前行。

本文是大数据解读篇，在这篇文章里我们将回顾2015展望2016，看看过去的一年里广受关注的技术有哪些进展，了解下数据科学家这个职业的火热。 在关键技术进展部分我们在大数据生态圈众多技术中选取了Hadoop、Spark、Elasticsearch和Apache Kylin四个点，分别请了四位专家：Hulu的董西成、明略数据的梁堰波、精硕科技的卢亿雷、eBay的韩卿，来为大家解读2015里的进展。

相关厂商内容

Twitter Messaging的架构演化之路

业务核心架构，根据业务需求设计合理架构

QCon北京2016大会，4月21-23日，与您相约北京国际会议中心，2月21前报名享8折优惠！

相关赞助商

QCon北京2016大会，4月21-23日，北京·国际会议中心，精彩内容邀您参与！

回顾2015年的关键技术进展：

Hadoop：

Hadoop作为大数据平台中最基础与重要的系统，在2015年提高稳定性的同时，发布了多个重要功能与特性，这使得Hadoop朝着多类型存储介质和异构集群的方向迈进了一大步。

• HDFS 

HDFS 之前是一个以磁盘单存储介质为主的分布式文件系统。但随着近几年新存储介质的兴起，支持多存储介质早就提上了日程。如今，HDFS 已经对多存储介质有了良好的支持，包括 Disk、Memory 和 SSD 等，对异构存储介质的支持，使得 HDFS 朝着异构混合存储方向发展。目前HDFS支持的存储介质如下：

ARCHIVE：高存储密度但耗电较少的存储介质，通常用来存储冷数据。

DISK：磁盘介质，这是HDFS最早支持的存储介质。

SSD：固态硬盘，是一种新型存储介质，目前被不少互联网公司使用。

RAM_DISK ：数据被写入内存中，同时会往该存储介质中再（异步）写一份。

• YARN

YARN作为一个分布式数据操作系统，主要作用是资源管理和资源调度。在过去一年，YARN新增了包括基于标签的调度、对长服务的支持、对 Docker 的支持等多项重大功能。

 基于标签的调度，使得 YARN 能够更好地支持异构集群调度。它的基本思想是，通过打标签的方式为不同的节点赋予不同的属性，这样，一个大的Hadoop集群按照节点类型被分成了若干个逻辑上相互独立（可能交叉）的集群。这种集群跟物理上独立的集群很不一样，用户可以很容易地通过动态调整 label，实现不同类型节点数目的增减，这具有很好的灵活性。

对长服务的支持，使得YARN逐渐变为一个通用资源管理和调度系统。目前，YARN既支持像类似 MapReduce，Spark 的短作业，也支持类似 Web Service，MySQL 这样的长服务。 支持长服务是非常难的一件事情，YARN 需要解决以下问题：服务注册、日志滚动、ResourceManager HA、NodeManager HA（NM 重启过程中，不影响 Container）和 ApplicationMaster 永不停止，重启后接管之前的 Container。截止2.7.0版本，以上问题都已经得到了比较完整的解决。

对Docker的支持，使得YARN能够为上层应用提供更好的打包、隔离和运行方式。YARN通过引入一种新的ContainerExecutor，即DockerContainerExecutor，实现了对Docker的支持，但目前仍然是alpha版本，不建议在生产环境中使用。

• HBase

在 2015 年，HBase 迎来了一个里程碑——HBase 1.0 release，这也代表着 HBase 走向了稳定。 HBase新增特性包括：更加清晰的接口定义，多 Region 副本以支持高可用读，Family 粒度的 Flush以及RPC 读写队列分离等。

Spark：

2015年的Spark发展很快，JIRA数目和PR数目都突破了10000，contributors数目超过了1000，可以说是目前最火的开源大数据项目。这一年Spark发布了多个版本，每个版本都有一些亮点：

• 2014年12月，Spark 1.2发布引入ML pipeline作为机器学习的接口。
• 2015年3月，Spark 1.3发布引入了DataFrame作为Spark的一个核心组件。
• 2015年6月，Spark 1.4发布引入R语言作为Spark的接口。R语言接口在问世一个多月之后的调查中就有18%的用户使用。
• 2015年9月，Spark 1.5发布。Tungsten项目第一阶段的产出合并入DataFrame的执行后端，DataFrame的执行效率得到大幅提升。
• 2016年1月，Spark 1.6发布引入Dataset接口。

Spark目前支持四种语言的接口，除了上面提到的R语言的使用率以外，Python的使用率也有很大提升，从2014年的38%提升到2015年的58%；而Scala接口的使用率有所下降，从84%下降到71%。同时Spark的部署环境也有所变化，51%的部署在公有云上，48% 使用standalone方式部署，而在YARN上的只有40%了。可见Spark已经超越Hadoop，形成了自己的生态系统。而在形成Spark生态系统中起到关键作用的一个feature就是外部数据源支持，Spark可以接入各种数据源的数据，然后把数据导入Spark中进行计算、分析、挖掘和机器学习，然后可以把结果在写出到各种各样的数据源。到目前为止Spark已经支持非常多的外部数据源，像Parquet/JSON/CSV/JDBC/ORC/HBase/Cassandra/Mongodb等等。

上面这些调查数据来自美国，中国的情况有所区别，但是还是有一定的借鉴意义的。国内的Spark应用也越来越多：腾讯的Spark规模到了8000+节点，日处理数据1PB+。阿里巴巴运行着目前最长时间的Spark Job：1PB+数据规模的Spark Job长达1周的时间。百度的硅谷研究院也在探索Spark+Tachyon的应用场景。

Spark MLlib的ALS算法已经在很多互联网公司用于其推荐系统中。基本上主流的互联网公司都已经部署了Spark平台并运行了自己的业务。上面说的更多的互联网的应用，实际上Spark的应用场景有很多。在Databricks公司的调查中显示主要应用依次是：商务智能、数据仓库、推荐系统、日志处理、欺诈检测等。

除了互联网公司以外，传统IT企业也把Spark作为其产品的一个重要组成。IBM在今年6月的Spark summit期间宣布重点支持Spark这个开源项目，同时还开源了自己的机器学习系统SystemML并推进其与Spark的更好合作。美国大数据巨头Cloudera，Hortonworks和MapR都表示Spark是其大数据整体解决方案的核心产品。可以预见Spark是未来若干年最火的大数据项目。

在深度学习方面2015年可谓非常热闹，如Google开源其第二代机器学习系统TensorFlow，Facebook开源Torch和人工智能硬件服务器Big Sur等等。Spark社区也不甘落后，在1.5版本中发布了一个神经网络分类器MultiplayerPerceptronClassifier作为其深度学习的雏形。虽然这个模型还有很多地方需要优化，大家不妨尝试下，毕竟它是唯一一个基于通用计算引擎的分布式深度学习系统。

除了现在非常火的深度学习，在传统统计和机器学习领域，Spark这一年也有非常大的变化，包括GLM的全面支持，SparkR GLM的支持，A/B test，以及像WeightesLeastSquares这样的底层优化算法等。

具体内容可以看梁堰波在InfoQ上的年终回顾：《解读2015之Spark篇：新生态系统的形成》。

Elasticsearch：

Elasticsearch 是一个可伸缩的开源全文搜索和分析引擎。它可以快速地存储、搜索和分析海量数据。Elasticsearch 基于成熟的 Apache Lucene 构建，在设计时就是为大数据而生，能够轻松的进行大规模的横向扩展，以支撑PB级的结构化和非结构化海量数据的处理。Elasticsearch生态圈发展状态良好，整合了众多外围辅助系统，如监控Marvel，分析Logstash，安全Shield等。近年来不断发展受到广泛应用，如Github、StackOverflow、维基百科等，是数据库技术中倍受关注的一匹黑马。

Elasticsearch在今年下半年发布了2.0版本，性能提升不少，主要改变为：

• Pipeline Aggregation

流式聚合，像管道一样，对聚合的结果进行再次聚合。原来client端需要做的计算工作，下推到ES，简化 client代码，更容易构建强大的查询。

• Query/Filter 合并

取消filters，所有的filter语句自动转换为query语句。在上下文语义是query时，进行相关性计算；上下文语 义是filter时，简单排除b不匹配的doc，像现在的filter所做的一样。这个重构以为着所有的query执行会以最 有效的顺序自动优化。例如，子查询和地理查询会首先执行一个快速的模糊步骤，然后用一个稍慢的精确 步骤截断结果。在filter上下文中，cache有意义时，经常使用的语句会被自动缓存。

• 可配置的store compression

存储的field，例如_source字段，可以使用默认的LZ4算法快速压缩，或者使用DEFLATE算法减少index size。对于日志类的应用尤其有用，旧的索引库在优化前可以切换到best_compression。

• Hardening

Elasticsearch运行于 Java Security Manager之下，在安全性上标志着一个巨大的飞跃。Elasticsearch难于探测，黑客在系统上 的影响也被严格限制。在索引方面也有加强： indexing请求ack前，doc会被fsync，默认写持久化 所有的文件都计算checksum，提前检测文件损坏 所有的文件rename操作都是原子的（atomic），避免部分写文件 对于系统管理员来讲，一个需求较多的变化是，可以避免一个未配置的node意外加入Elasticsearch集群网络：默认绑 定localhost only， multicast也被移除，鼓励使用unicast。

• Performance and Resilience

除上所述，Elasticsearch和Lucene还有很多小的变化，使其更加稳定可靠，易于配置，例如：

默认doc value，带来更少的heap usage，filter caching 更多使用 bitsets type mappings 大清理，更安全可靠，无二义性 cluster stat 使用diff进行快速变化传播，带来更稳定的大规模集群

• Core plugins

官方支持的core plugins同时发布，和Elasticsearch核心使用相同的版本号。

• Marvel 2.0.0 free to use in production

Marvel免费。

Apache Kylin：

Apache Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。最初于2014年10月1日开源，并于同年11月加入Aapche孵化器项目，并在一年后的2015年11月顺利毕业成为Apache顶级项目，是eBay全球贡献至Apache软件基金会（ASF）的第一个项目，也是全部由在中国的华人团队整体贡献至Apache的第一个项目。

在eBay，已经上线两个生产环境平台，有着诸多的应用，包括用户行为分析、点击分析、商户分析、交易分析等应用，最新的Streaming分析项目也已经上线。目前在eBay平台上最大的单个cube包含了超过1000亿的数据，90%查询响应时间小于1.5秒，95%的查询响应时间小于5秒。同时Apache Kylin在eBay外部也有很多的用户，包括京东、美团、百度地图、网易、唯品会、Expedia、Expotional等很多国内外公司也已经在实际环境中使用起来，把Apache Kylin作为他们大数据分析的基础之一。

过去的一年多是Apache Kylin发展的重要的一年：

• 2014年10月1日，Kylin 代码在github.com上正式开源
• 2014年11月25日，正式加入Apache孵化器并正式启用Apache Kylin作为项目名称
• 2015年6月10日，Apache Kylin v0.7.1-incubating发布，这是加入Apache后的第一个版本，依据Apache的规范作了很多修改，特别是依赖包，license等方面，同时简化了安装，设置等，并同时提供二进制安装包
• 2015年9月6日，Apache Kylin v1.0-incubating正式发布，增强了SQL处理，提升了HBase coprocessor 的性能，同时提供了Zeppelin Interpreter等
• 2015年9月16日，Apache Kylin与Spark，Kafka，Storm，H2O，Flink，Elasticsearch，Mesos等一起荣获InfoWorld Bossie Awards 2015：最佳开源大数据工具奖，这是业界对Kylin的认可
• 2015年11月18日，Apache Kylin正式毕业成为Apache顶级项目
• 2015年12月15日，Apache Kylin v1.2正式发布，这是升级为顶级项目后的第一个版本，提供了对Excel，PowerBI，Tableau 9等的支持，对高基维度增强了支持，修复了多个关键Bug等
• 2016年，Apache Kylin将迎来重要的2.x版本，该版本对底层架构和设计作了重大重构，提供可插拔的设计及Lambda架构，同时提供对历史数据查询，Streaming及Realtime查询等，同时在性能，任务管理，UI等各个方面提供增强。

同时，过去一年也是社区发展的重要一年，在过去一年内发展了来自eBay，美团，京东，明略数据，网易等众多committer，社区每天的讨论也是非常热闹。社区提交了很多新特性和Bug修复，包括来自美团的不同HBase写入，来自京东的明细数据查询，来自网易的多Hive源等多个重大特性为Apache Kylin带来了巨大的增强。

社区合作

在开源后的一年时间内，Apache Kylin也和其他社区建立了良好的合作关系，Apache Calcite作为Kylin 的SQL引擎被深入的整合进来，我们也向Calcite提交了很多改进和修复，Calcite的作者，Julian Hyde也是Kylin的mentor。HBase是Kylin的存储层，在实际运维中，我们碰到过无数问题，从可靠性到性能到其他各个方面，Kylin社区和HBase社区积极合作解决了绝大部分关键问题。另外，现在越来越多的用户考虑使用Apache Zeppelin作为前端查询和展现的工具，为此我们开发了Kylin Interperter并贡献给了Zeppelin，目前可以直接从最新版的Zeppelin代码库中看到这块。同样，我们也和其他各个社区积极合作，包括Spark，Kafka等，为构建和谐的社区氛围和形成良好合作打下了坚实的基础。

技术发展

技术上，这一年来Apache Kylin主要在以下几个方面

• Fast Cubing

在现在的版本中，Cube的计算依赖MapReduce，并且需要多个步骤的MR Job来完成计算，且MR Job的多少和维度相关，越多的维度会带来更多的MR job。而每一次MR job的启停都需要等待集群调度，并且MR job之间的数据需要多次在HDFS落地和传输，从而导致消耗了大量的集群资源。为此我们引入了一种新的算法：Fast Cubing。一个MapReduce即可完成Cub的计算，测试结果表明整个Cubing的时间可以降低30～50%左右，网络传输可以下降5倍，这在超大规模数据集的计算上带来了客观的性能改进。

• Streaming OLAP

Kylin作为一个预计算系统，不可避免的有着数据刷新延迟的限制，这在大部分用户案例中并不是问题，但随着业务和技术的发展，Streaming甚至Realtime的需求越来越高。2015年Kylin的主要发展都在Streaming OLAP上，为了支持低延迟的数据刷新，从整体的架构和设计上都做了相当大的重新设计，目前已经可以支持从Kafka读取数据并进行聚合计算的能力，同时提供SQL接口为前端客户端提供标准的访问接口，数据延迟已经可以做到分钟级别。

• Spark Cubing

Spark作为MapReduce的一种替代方案一直在社区中被问及Kylin是否可以支持直接使用Spark来作为计算。为此我们在2015年下半年实现了同样算法的Spark Cubing引擎，目前还在测试中。

• 可插拔架构

为了更广泛的可扩展性，并支持如上各种新特性，Kylin在2.x的代码中引入了可插拔架构和设计，从而解决了对特定技术的依赖问题。在新的设计中，数据源可以从Hive，SparkSQL等各种SQL on Hadoop技术读取，并支持Kafka；在计算引擎方面，除了MapReduce方面的Fast Cubing外，实现了Spark Cubing，Streaming Cubing等多种计算框架，并为将来其他计算框架留下了扩展接口；在存储上，HBase目前依然是唯一的存储层，但在上层设计中已经很好的进行了抽象，很容易可以扩展到其他Key－Value系统。

大数据与机器学习

机器学习是数据分析不可缺少的一部分。机器学习被赞誉为大数据分析和商务智能发展的未来，成功的机器学习项目依赖于很多因素，包括选择正确的主题，运行环境，合理的机器学习模型，最重要的是现有的数据，大数据为机器学习提供了很好的用武之地。

机器学习正很快从一个被很少人关注的技术主题转变为被很多人使用的管理工具。优秀的算法，大数据和高性能的计算资源的条件的满足使得机器学习快速发展，机器学习在今年第一次进入Gartner技术成熟曲线的报告中，并且进入大数据一样的应用期；而机器学习也是报告中第一个出现的技术。2015年是机器学习丰收年，发生了很多令人瞩目的大事。

各大巨头开源：

• 2015年1月，Facebook开源前沿深度学习工具“Torch”。
• 2015年4月，亚马逊启动其机器学习平台Amazon Machine Learning，这是一项全面的托管服务，让开发者能够轻松使用历史数据开发并部署预测模型。
• 2015年11月，谷歌开源其机器学习平台TensorFlow。
• 同一月，IBM开源SystemML并成为Apache官方孵化项目。
• 同时，微软亚洲研究院将分布式机器学习工具DMTK通过Github开源。DMTK由一个服务于分布式机器学习的框架和一组分布式机器学习算法组成，可将机器学习算法应用到大数据中。
• 2015年12月，Facebook开源针对神经网络研究的服务器“Big Sur”，配有高性能图形处理单元（GPUs），转为深度学习方向设计的芯片。

大公司不仅是用开源社区来增强自己的机器学习工具，而且也会以收购来提升自身的机器学习实力。如IBM于今年3月收购了AIchemyAPI，AIchemyAPI能够利用深度学习人工智能，搜集企业、网站发行的图片和文字等来进行文本识别和数据分析。

此外，2015年不仅仅是关于大公司的，利用机器学习的各种创业公司也占了同等地位。比如EverString完成B轮融资，该公司利用企业内部销售数据，和不断主动挖掘分析全球新闻数据，社交媒体等外部数据，通过机器学习自动建立量化客户模型，为企业预测潜在客户。

数据科学家的崛起

大数据需要数据分析，数据分析需要人才。数据科学是早就存在的词汇，而数据科学家却是近年来突然出现的新词。在Google、Amazon、Quora、Facebook等大公司的背后，都有一批数据科学专业人才，将大量数据变为可开发有价值的金矿。在大数据时代，数据科学家等分析人才的需求在激增。

据相关报告，国内大数据人才缺口目前已达百万，一名高级数据挖掘工程师月薪高达30K-50K。招聘网站上的每天都会产生大量的大数据相关职位需求。据拉勾网提供的统计来看，从2014年到2015年，IT行业关于大数据的岗位需求增长了2.4倍。人才培养迫在眉睫。复旦大学于今年成立了全国首个大数据学院。阿里云于年底宣布新增30所合作高校，开设云计算大数据专业,计划用3年时间培养5万名数据科学家。各知名大学也将数据科学设为硕士课程。

无论是国内还是国外，数据科学都是目前炙手可热的研究领域，数据科学家、数据分析师都是非常火爆的职位，几乎所有的产业都需要数据科学家来从大量的数据中挖掘有价值的信息。大数据分析领域的专属首席级别头衔也愈发多见。美国政府今年任命了DJ Patil作为政府的首席数据科学家（Chief Data Scientist），这也是美国政府内部首次设立“数据科学家”这个职位。

展望2016：

• Hadoop。对于 HDFS，会朝着异构存储介质方向发展，尤其是对新兴存储介质的支持；对于 YARN，会朝着通用资源管理和调度方向发展，而不仅仅限于大数据处理领域，在加强对 MapReduce、Spark等短类型应用支持的同时，加强对类似Web Service 等长服务的支持；
• 对于HBase，将会花费更多精力在稳定性和性能方面，正尝试的技术方向包括：对于 HDFS 多存储介质的使用；减少对 ZooKeeper 的使用以及通过使用堆外内存缓解Java GC的影响。
• Spark 2.0预计明年三四月份发布，将会确立以DataFrame和Dataset为核心的体系架构。同时在各方面的性能上会有很大的提升。
• Apache Kylin 2.0即将发布，随着各项改进的不断完善，该版本将在2016年在OLAP on Hadoop上更进一步！
• Elasticsearch开源搜索平台，机器学习，Data graphics，数据可视化在2016年会更加火热。
• 大数据会越来越大，IOT、社交媒体依然是一个主要的推动因素。
• 大数据的安全和隐私会持续受到关注。

专家介绍：

董西成 就职于Hulu，专注于分布式计算和资源管理系统等相关技术。《Hadoop 技术内幕：深入解析 MapReduce 架构设计与实现原理》和《Hadoop 技术内幕：深入解 析 YARN 架构设计与实现原理》作者，dongxicheng.org 博主。

梁堰波 明略数据技术合伙人，开源爱好者，Apache Spark项目核心贡献者。北京航空航天大学计算机硕士，曾就职于Yahoo!、美团网、法国电信从事机器学习和推荐系统相关的工作，在大数据、机器学习和分布式系统领域具备丰富的项目经验。

卢亿雷 精硕科技(AdMaster)技术副总裁兼总架构师，大数据资深专家，CCF（中国计算学会）大数据专委委员，北航特聘教授。主要负责数据的采集、清洗、存储、挖掘等整个数据流过程，确保提供高可靠、高可用、高扩展、高性能系统服务，提供Hadoop/HBase/Storm/Spark/ElasticSearch等离线、流式及实时分布式计算服务。对分布式存储和分布式计算、超大集群、大数据分析等有深刻理解及实践经验。有超过10年云计算、云存储、大数据经验。曾在联想、百度、Carbonite工作，并拥有多篇大数据相关的专利和论文。

韩卿(Luke Han) eBay全球分析基础架构部(ADI) 大数据平台产品负责人，Apache Kylin 副总裁，联合创始人，管理和驱动着Apache Kylin的愿景，路线图，特性及计划等，在全球各地不同部门中发展客户，开拓内外部合作伙伴及管理开源社区等，建立与大数据厂商，集成商及最终用户的联系已构建健壮的Apache Kylin生态系统。在大数据，数据仓库，商务智能等方面拥有超过十年的工作经验。

微服务(MicroServices)架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点(technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。

服务注册、发现、负载均衡和健康检查

和单块(Monolithic)架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡LB所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种：

第一种是集中式LB方案，如下图Fig 1，在服务消费者和服务提供者之间有一个独立的LB，LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现。LB上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向LB发起请求，由LB以某种策略（比如Round-Robin）做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现LB呢？通常的做法是通过DNS，运维人员为服务配置一个DNS域名，这个域名指向LB。

Fig 1, 集中式LB方案

集中式LB方案实现简单，在LB上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式LB的主要问题是单点问题，所有服务调用流量都经过LB，当服务数量和调用量大的时候，LB容易成为瓶颈，且一旦LB发生故障对整个系统的影响是灾难性的。另外，LB在服务消费方和服务提供方之间增加了一跳(hop)，有一定性能开销。

第二种是进程内LB方案，针对集中式LB的不足，进程内LB方案将LB的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载(Soft Load Balancing)或者客户端负载方案，下图Fig 2展示了这种方案的工作原理。这一方案需要一个服务注册表(Service Registry)配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的LB组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性(Availability)要求很高，一般采用能满足高可用分布式一致的组件（例如Zookeeper, Consul, Etcd等）来实现。

Fig 2, 进程内LB方案

进程内LB方案是一种分布式方案，LB和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库(Client Library)的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。

进程内LB的案例是Netflix的开源服务框架，对应的组件分别是：Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查，Ribbon客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架Dubbo也是采用类似机制。

第三种是主机独立LB进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将LB和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立LB进程做服务发现和负载均衡，见下图Fig 3。

Fig 3 主机独立LB进程方案

该方案也是一种分布式方案，没有单点问题，一个LB进程挂了只影响该主机上的服务调用方，服务调用方和LB之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。

该方案的典型案例是Airbnb的SmartStack服务发现框架，对应组件分别是：Zookeeper作为服务注册表，Nerve独立进程负责服务注册和健康检查，Synapse/HAproxy独立进程负责服务发现和负载均衡。Google最新推出的基于容器的PaaS平台Kubernetes，其内部服务发现采用类似的机制。

服务前端路由

微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用：

1. 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。
2. 安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。
3. 限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。
4. 监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。
5. 日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

Fig 4, 服务网关

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，特点是动态可热部署的过滤器(filter)机制，其它如HAproxy，Nginx等都可以扩展作为网关使用。

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(Fig 5)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在下图Fig 5的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

Fig 5, 简化的微服务架构图

服务容错

当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为1 -> N扇出(见图Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成所谓的雪崩效应(Cascading Failure，见图Fig 7)，严重时可致整个网站瘫痪。

Fig 6, 服务依赖

Fig 7, 高峰期单个服务延迟致雪崩效应

经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括：

1. 电路熔断器模式(Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图Fig 8是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态(Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。



Fig 8, 弹性电路保护状态图

2. 舱壁隔离模式(Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离(Thread Isolation)就是舱壁隔离模式的一个例子，假定一个应用程序A调用了Svc1/Svc2/Svc3三个服务，且部署A的容器一共有120个工作线程，采用线程隔离机制，可以给对Svc1/Svc2/Svc3的调用各分配40个线程，当Svc2慢了，给Svc2分配的40个线程因慢而阻塞并最终耗尽，线程隔离可以保证给Svc1/Svc3分配的80个线程可以不受影响，如果没有这种隔离机制，当Svc2慢的时候，120个工作线程会很快全部被对Svc2的调用吃光，整个应用程序会全部慢下来。
3. 限流(Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量(秒杀，双十一)时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许100个并发调用，对超过这个限制的请求要拒绝并回退。
4. 回退(fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败(Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。

Netflix将上述容错模式和最佳实践集成到一个称为Hystrix的开源组件中，凡是需要容错的依赖点(服务，缓存，数据库访问等)，开发人员只需要将调用封装在Hystrix Command里头，则相关调用就自动置于Hystrix的弹性容错保护之下。Hystrix组件已经在Netflix经过多年运维验证，是Netflix微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。

服务框架

微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架(Fig 9)主要封装公共关注点逻辑，包括：

Fig 9, 服务框架

1. 服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
2. 监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
3. REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
5. 限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
6. 管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
7. 统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
8. 安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
9. 文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

当前业界比较成熟的微服务框架有Netflix的Karyon/Ribbon，Spring的Spring Boot/Cloud，阿里的Dubbo等。

运行期配置管理

服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境(开发/测试/生产)一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图(Fig 10):

Fig 10, 服务配置中心

动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉(Scheduled Pull)的方式或者服务器推(Server-side Push)的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销(假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。

配置中心比较成熟的开源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。

Netflix的微服务框架

Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括：

1. Eureka:　服务注册发现框架
2. Zuul:　服务网关
3. Karyon:　服务端框架
4. Ribbon:　客户端框架
5. Hystrix: 服务容错组件
6. Archaius: 服务配置组件
7. Servo: Metrics组件
8. Blitz4j: 日志组件

下图Fig 11展示了基于这些组件构建的一个微服务框架体系，来自recipes-rss。

Fig 11, 基于Netflix开源组件的微服务框架

Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴Netflix的开源微服务组件(或Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。

ZooKeeper responds to a small set of commands. Each command is composed of four letters. You issue the commands to ZooKeeper via telnet or nc, at the client port.

Three of the more interesting commands: "stat" gives some general information about the server and connected clients, while "srvr" and "cons" give extended details on server and connections respectively.

conf

New in 3.3.0: Print details about serving configuration.

cons

New in 3.3.0: List full connection/session details for all clients connected to this server. Includes information on numbers of packets received/sent, session id, operation latencies, last operation performed, etc...

crst

New in 3.3.0: Reset connection/session statistics for all connections.

dump

Lists the outstanding sessions and ephemeral nodes. This only works on the leader.

envi

Print details about serving environment

ruok

Tests if server is running in a non-error state. The server will respond with imok if it is running. Otherwise it will not respond at all.

A response of "imok" does not necessarily indicate that the server has joined the quorum, just that the server process is active and bound to the specified client port. Use "stat" for details on state wrt quorum and client connection information.

srst

Reset server statistics.

srvr

New in 3.3.0: Lists full details for the server.

stat

Lists brief details for the server and connected clients.

wchs

New in 3.3.0: Lists brief information on watches for the server.

wchc

New in 3.3.0: Lists detailed information on watches for the server, by session. This outputs a list of sessions(connections) with associated watches (paths). Note, depending on the number of watches this operation may be expensive (ie impact server performance), use it carefully.

wchp

New in 3.3.0: Lists detailed information on watches for the server, by path. This outputs a list of paths (znodes) with associated sessions. Note, depending on the number of watches this operation may be expensive (ie impact server performance), use it carefully.

mntr

New in 3.4.0: Outputs a list of variables that could be used for monitoring the health of the cluster.

$ echo mntr | nc localhost 2185  zk_version  3.4.0 zk_avg_latency  0 zk_max_latency  0 zk_min_latency  0 zk_packets_received 70 zk_packets_sent 69 zk_outstanding_requests 0 zk_server_state leader zk_znode_count   4 zk_watch_count  0 zk_ephemerals_count 0 zk_approximate_data_size    27 zk_followers    4                   - only exposed by the Leader zk_synced_followers 4               - only exposed by the Leader zk_pending_syncs    0               - only exposed by the Leader zk_open_file_descriptor_count 23    - only available on Unix platforms zk_max_file_descriptor_count 1024   - only available on Unix platforms 

The output is compatible with java properties format and the content may change over time (new keys added). Your scripts should expect changes.

ATTENTION: Some of the keys are platform specific and some of the keys are only exported by the Leader.

The output contains multiple lines with the following format:

key \t value

Here's an example of the ruok command:

$ echo ruok | nc 127.0.0.1 5111 imok

背景
在很多互联网产品应用中，有些场景需要加锁处理，比如：秒杀，全局递增ID，楼层生成等等。大部分的解决方案是基于DB实现的，Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系。其次Redis提供一些命令SETNX，GETSET，可以方便实现分布式锁机制。

Redis命令介绍
使用Redis实现分布式锁，有两个重要函数需要介绍

SETNX命令（SET if Not eXists）
语法：
SETNX key value
功能：
当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。

GETSET命令
语法：
GETSET key value
功能：
将给定 key 的值设为 value ，并返回 key 的旧值 (old value)，当 key 存在但不是字符串类型时，返回一个错误，当key不存在时，返回nil。

GET命令
语法：
GET key
功能：
返回 key 所关联的字符串值，如果 key 不存在那么返回特殊值 nil 。

DEL命令
语法：
DEL key [KEY …]
功能：
删除给定的一个或多个 key ,不存在的 key 会被忽略。

兵贵精，不在多。分布式锁，我们就依靠这四个命令。但在具体实现，还有很多细节，需要仔细斟酌，因为在分布式并发多进程中，任何一点出现差错，都会导致死锁，hold住所有进程。

加锁实现

SETNX 可以直接加锁操作，比如说对某个关键词foo加锁，客户端可以尝试
SETNX foo.lock <current unix time>

如果返回1，表示客户端已经获取锁，可以往下操作，操作完成后，通过
DEL foo.lock

命令来释放锁。
如果返回0，说明foo已经被其他客户端上锁，如果锁是非堵塞的，可以选择返回调用。如果是堵塞调用调用，就需要进入以下个重试循环，直至成功获得锁或者重试超时。理想是美好的，现实是残酷的。仅仅使用SETNX加锁带有竞争条件的，在某些特定的情况会造成死锁错误。

处理死锁

在上面的处理方式中，如果获取锁的客户端端执行时间过长，进程被kill掉，或者因为其他异常崩溃，导致无法释放锁，就会造成死锁。所以，需要对加锁要做时效性检测。因此，我们在加锁时，把当前时间戳作为value存入此锁中，通过当前时间戳和Redis中的时间戳进行对比，如果超过一定差值，认为锁已经时效，防止锁无限期的锁下去，但是，在大并发情况，如果同时检测锁失效，并简单粗暴的删除死锁，再通过SETNX上锁，可能会导致竞争条件的产生，即多个客户端同时获取锁。

C1获取锁，并崩溃。C2和C3调用SETNX上锁返回0后，获得foo.lock的时间戳，通过比对时间戳，发现锁超时。
C2 向foo.lock发送DEL命令。
C2 向foo.lock发送SETNX获取锁。
C3 向foo.lock发送DEL命令，此时C3发送DEL时，其实DEL掉的是C2的锁。
C3 向foo.lock发送SETNX获取锁。

此时C2和C3都获取了锁，产生竞争条件，如果在更高并发的情况，可能会有更多客户端获取锁。所以，DEL锁的操作，不能直接使用在锁超时的情况下，幸好我们有GETSET方法，假设我们现在有另外一个客户端C4，看看如何使用GETSET方式，避免这种情况产生。

C1获取锁，并崩溃。C2和C3调用SETNX上锁返回0后，调用GET命令获得foo.lock的时间戳T1，通过比对时间戳，发现锁超时。
C4 向foo.lock发送GESET命令，
GETSET foo.lock <current unix time>
并得到foo.lock中老的时间戳T2

如果T1=T2，说明C4获得时间戳。
如果T1!=T2，说明C4之前有另外一个客户端C5通过调用GETSET方式获取了时间戳，C4未获得锁。只能sleep下，进入下次循环中。

现在唯一的问题是，C4设置foo.lock的新时间戳，是否会对锁产生影响。其实我们可以看到C4和C5执行的时间差值极小，并且写入foo.lock中的都是有效时间错，所以对锁并没有影响。
为了让这个锁更加强壮，获取锁的客户端，应该在调用关键业务时，再次调用GET方法获取T1，和写入的T0时间戳进行对比，以免锁因其他情况被执行DEL意外解开而不知。以上步骤和情况，很容易从其他参考资料中看到。客户端处理和失败的情况非常复杂，不仅仅是崩溃这么简单，还可能是客户端因为某些操作被阻塞了相当长时间，紧接着 DEL 命令被尝试执行(但这时锁却在另外的客户端手上)。也可能因为处理不当，导致死锁。还有可能因为sleep设置不合理，导致Redis在大并发下被压垮。最为常见的问题还有

GET返回nil时应该走那种逻辑？

第一种走超时逻辑
C1客户端获取锁，并且处理完后，DEL掉锁，在DEL锁之前。C2通过SETNX向foo.lock设置时间戳T0 发现有客户端获取锁，进入GET操作。
C2 向foo.lock发送GET命令，获取返回值T1(nil)。
C2 通过T0>T1+expire对比，进入GETSET流程。
C2 调用GETSET向foo.lock发送T0时间戳，返回foo.lock的原值T2
C2 如果T2=T1相等，获得锁，如果T2!=T1，未获得锁。

第二种情况走循环走setnx逻辑
C1客户端获取锁，并且处理完后，DEL掉锁，在DEL锁之前。C2通过SETNX向foo.lock设置时间戳T0 发现有客户端获取锁，进入GET操作。
C2 向foo.lock发送GET命令，获取返回值T1(nil)。
C2 循环，进入下一次SETNX逻辑

两种逻辑貌似都是OK，但是从逻辑处理上来说，第一种情况存在问题。当GET返回nil表示，锁是被删除的，而不是超时，应该走SETNX逻辑加锁。走第一种情况的问题是，正常的加锁逻辑应该走SETNX，而现在当锁被解除后，走的是GETST，如果判断条件不当，就会引起死锁，很悲催，我在做的时候就碰到了，具体怎么碰到的看下面的问题

GETSET返回nil时应该怎么处理？

C1和C2客户端调用GET接口，C1返回T1，此时C3网络情况更好，快速进入获取锁，并执行DEL删除锁，C2返回T2(nil)，C1和C2都进入超时处理逻辑。
C1 向foo.lock发送GETSET命令，获取返回值T11(nil)。
C1 比对C1和C11发现两者不同，处理逻辑认为未获取锁。
C2 向foo.lock发送GETSET命令，获取返回值T22(C1写入的时间戳)。
C2 比对C2和C22发现两者不同，处理逻辑认为未获取锁。

此时C1和C2都认为未获取锁，其实C1是已经获取锁了，但是他的处理逻辑没有考虑GETSET返回nil的情况，只是单纯的用GET和GETSET值就行对比，至于为什么会出现这种情况？一种是多客户端时，每个客户端连接Redis的后，发出的命令并不是连续的，导致从单客户端看到的好像连续的命令，到Redis server后，这两条命令之间可能已经插入大量的其他客户端发出的命令，比如DEL,SETNX等。第二种情况，多客户端之间时间不同步，或者不是严格意义的同步。

时间戳的问题

我们看到foo.lock的value值为时间戳，所以要在多客户端情况下，保证锁有效，一定要同步各服务器的时间，如果各服务器间，时间有差异。时间不一致的客户端，在判断锁超时，就会出现偏差，从而产生竞争条件。
锁的超时与否，严格依赖时间戳，时间戳本身也是有精度限制，假如我们的时间精度为秒，从加锁到执行操作再到解锁，一般操作肯定都能在一秒内完成。这样的话，我们上面的CASE，就很容易出现。所以，最好把时间精度提升到毫秒级。这样的话，可以保证毫秒级别的锁是安全的。

分布式锁的问题

1：必要的超时机制：获取锁的客户端一旦崩溃，一定要有过期机制，否则其他客户端都降无法获取锁，造成死锁问题。
2：分布式锁，多客户端的时间戳不能保证严格意义的一致性，所以在某些特定因素下，有可能存在锁串的情况。要适度的机制，可以承受小概率的事件产生。
3：只对关键处理节点加锁，良好的习惯是，把相关的资源准备好，比如连接数据库后，调用加锁机制获取锁，直接进行操作，然后释放，尽量减少持有锁的时间。
4：在持有锁期间要不要CHECK锁，如果需要严格依赖锁的状态，最好在关键步骤中做锁的CHECK检查机制，但是根据我们的测试发现，在大并发时，每一次CHECK锁操作，都要消耗掉几个毫秒，而我们的整个持锁处理逻辑才不到10毫秒，玩客没有选择做锁的检查。
5：sleep学问，为了减少对Redis的压力，获取锁尝试时，循环之间一定要做sleep操作。但是sleep时间是多少是门学问。需要根据自己的Redis的QPS，加上持锁处理时间等进行合理计算。
6：至于为什么不使用Redis的muti，expire，watch等机制，可以查一参考资料，找下原因。

锁测试数据

未使用sleep
第一种，锁重试时未做sleep。单次请求，加锁，执行，解锁时间 


可以看到加锁和解锁时间都很快，当我们使用

ab -n1000 -c100 'http://sandbox6.wanke.etao.com/test/test_sequence.php?tbpm=t'
AB 并发100累计1000次请求，对这个方法进行压测时。 


我们会发现，获取锁的时间变成，同时持有锁后，执行时间也变成，而delete锁的时间，将近10ms时间，为什么会这样？
1：持有锁后，我们的执行逻辑中包含了再次调用Redis操作，在大并发情况下，Redis执行明显变慢。
2：锁的删除时间变长，从之前的0.2ms，变成9.8ms，性能下降近50倍。
在这种情况下，我们压测的QPS为49，最终发现QPS和压测总量有关，当我们并发100总共100次请求时，QPS得到110多。当我们使用sleep时

使用Sleep时

单次执行请求时

我们看到，和不使用sleep机制时，性能相当。当时用相同的压测条件进行压缩时 

获取锁的时间明显变长，而锁的释放时间明显变短，仅是不采用sleep机制的一半。当然执行时间变成就是因为，我们在执行过程中，重新创建数据库连接，导致时间变长的。同时我们可以对比下Redis的命令执行压力情况 

上图中细高部分是为未采用sleep机制的时的压测图，矮胖部分为采用sleep机制的压测图，通上图看到压力减少50%左右，当然，sleep这种方式还有个缺点QPS下降明显，在我们的压测条件下，仅为35，并且有部分请求出现超时情况。不过综合各种情况后，我们还是决定采用sleep机制，主要是为了防止在大并发情况下把Redis压垮，很不行，我们之前碰到过，所以肯定会采用sleep机制。

参考资料

http://www.worlduc.com/FileSystem/18/2518/590664/9f63555e6079482f831c8ab1dcb8c19c.pdf
http://redis.io/commands/setnx
http://www.blogjava.net/caojianhua/archive/2013/01/28/394847.html

from: http://wapapp.baidu.com/tianhuimin/item/6e144c362eced2ff96f88d42

1 概述1.1 研发背景

支撑互联网应用的各种服务通常都是用复杂大规模分布式集群来实现的。而这些互联网应用又构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开 发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工 具。

hydra分布式跟踪系统就为了解决以上这些问题而设计的。

Google的论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我们设计开发的指导思想(原文和译文地址 https://github.com/bigbully/Dapper-translation)。Google针对自己的分布式跟踪系统Dapper 在生产环境下运行两年多时间积累的经验，在论文中重点提到了分布式跟踪系统对业务系统的零侵入这个先天优势，并总结了大量的应用场景，还提及它的不足之 处。我们通过对这篇论文的深入研究，并参考了Twitter同样依据这篇论文的scala实现Zipkin，结合我们自身的现有架构，我们认为分布式跟踪 系统在我们内部是非常适合的，而且也是急需的。

hydra目前的功能并不复杂，他可以接入一些基础组件，然后实现在基础组件上收集在组建上产生的行为的时间消耗，并且提供跟踪查询页面，对跟踪到的数据进行查询和展示。

我们会在之后的功能介绍中对hydra现有功能进行说明。

分布式跟踪的领域模型其实已经很成熟，早在1997年IBM就把ARM2.0(Application Response Measurement)作为一个公开的标准提供给了Open Group，无奈当时SOA的架构还未成熟，对业务的跟踪还需要直接嵌入到业务代码中，致使跟踪系统无法顺利推广。

如今互联网领域大多数后台服务都已经完成了SOA化，所以对业务的跟踪可以直接简化为对服务调用框架的跟踪，所以越来越多的跟踪系统也涌现出来。 在hydra系统中，我们使用的领域模型参考了Google的Dapper和Twitter的Zipkin(http://twitter.github.io/zipkin/)。

参考Dapper和Zipkin的设计，hydra也提炼出了自己的领域模型，如图所示:

• Trace:一次服务调用追踪链路。

• Span:追踪服务调基本结构，多span形成树形结构组合成一次Trace追踪记录。

• Annotation:在span中的标注点，记录整个span时间段内发生的事件。

• BinaryAnnotation:属于Annotation一种类型和普通Annotation区别，这键值对形式标注在span中发生的事件，和一些其他相关的信息。

Annotation在整个跟踪数据模型中最灵活的，灵活运用annotation基本能表达你所想到的跟踪场景。在hydra中(参考了zipkin)定义4种不同value的annotation用来表达记录span 4个最基本的事件。通过这4个annotation能计算出链路中业务消耗和网络消耗时间。

公司内部，尤其是我们部门有很多业务系统使用dubbo作为服务调用框，所以我们的分布式跟踪系统第一个接入组件就是dubbo。 另一个原因也是因为我们团队对dubbo有着非常深入的理解，加之dubbo本身的架构本身十分适合扩展，作为服务调用框架而言，跟踪的效果会非常明显， 比如Twitter的Zipkin也是植入到内部的Finagle服务调用框架上来进行跟踪的。

由于现阶段hydra主要接入了dubbo服务调用框架,所以在这必须了解dubbo的几个模型，如下图所示:

• Application:一类业务类型的服务，下面可能包含多个接口服务，可能出现多种类型业务跟踪链路。

• InterfaceService:接口服务，一个服务接口提供多种业务处理方法。

• Method:接口服务中具体处理业务的方法。

如图所示的应用场景对A服务的调用。A服务在被调用的过程中会继续调用服务B和服务C,而服务C被调用之后又会继续调用服务D和服 务E。在我们的领域模型中，服务A被调用到调用完成的过程，就是一次trace。而每一个服务被调用并返回的过程（一去一回的箭头）为一个span。可以 看到这个示例中包含5个span，client-A，A-B，A-C，C-D，C-E。span本身以树形结构展开，A-C是C-D和C-E的父 span，而client-A是整个树形结构的root span。之后要提到的一个概念就是annotation，annotation代表在服务调用过程中发生的一些我们感兴趣的事情，如图所示C-E上标出 来的那四个点，就是四个annotation，来记录事件时间戳，分别是C服务的cs（client send），E服务的ss（server receive）,E服务的ss（server send）, C服务的cr（client receive）。如果有一些自定义的annotation我们会把它作为BinaryAnnotation，其实就是一个k-v对，记录任何跟踪系统想 记录的信息，比如服务调用中的异常信息，重要的业务信息等等。

当前hydra1.0版的功能主要分为两个部分，跟踪查询和跟踪展示。

如图所示为查询页面：

在hydra针对业务提出两个相关的概念：应用和服务。不同的业务的所属不同的应用(相当于dubbo中的Application)，服务（相当于dubbo中的interface）挂在应用之下。

在hydra的查询界面中首先要选择想要关注的应用名，然后通过自动完成的方式输入应用下的服务。选择服务的开始时间和需要查看的跟踪次数。另外hydra需要确定返回数据的总量，防止查询出大数据量导致页面失去响应。

另外我们提供对额外的筛选条件：调用响应时间、是否发生异常。调用响应时间指的是这一次服务调用从调用开始到调用结束的时间，是否发生异常则包括一次服务调用中所有历经的服务抛出的异常都会捕获到。

对于查询之后的数据，hydra提供在前台进行排序的功能。

对于每一次跟踪，我们可以进一步展示他的服务调用层级与响应时间的时序图。如下图所示：

我们参考Dapper中论述的场景，在时序图中用绿色代表服务调用时间，浅蓝色代表网络耗时，另外如果服务调用抛出异常被 hydra捕捉到的话，会用红色表示。鼠标移动到时序图中的每一个对象上，会Tip展现详细信息，包括服务名、方法名、调用时长、Endpoint、异常 信息等。

左侧的树形结构图可以收起和展开，同时右侧的时序图产生联动，利于调整关注点在不同的服务上。

对于分布式跟踪系统而言，必须对接入的基础组件进行改造，我们对dubbo的改造很简单，只是在过滤器链上增加一个过滤器，我们将其封装成一个hydra-dubbo的jar包，由dubbo直接依赖。

所有跟踪所需的通用性的API我们封装在hydra-client中，遍于接入各种组件。 hydra-manager用来完成每个服务的注册、采样率的调成、发送seed生成全局唯一的traceId等通用性的功能。所有hydra-manager数据统一用mysql进行存储。

我们使用hydra-collector和hydra-collector-service进行跟踪数据的异步存储，中间使用metaQ进行缓冲。

hydra-manager和hydra-collector使用dobbo提供服务。

考虑到数据量不大的情况，以及部署的复杂度。我们提供了两种更简便的架构

• 如果考虑到数据量没有那么大，可以不使用hbase，用mysql代替，即精简版1。因为毕竟hadoop集群和hbase集群的部署和维护工作量很大。

• 如果并发量也不是很大的话，可以不使用消息中间件，也就是精简版2，如图所示。在hydra-collector端直接进行数据落地，当然仍然是异步的。

在使用mysql进行存储的时候我们并未进行分库分表，因为考虑到存储的是监控数据，时效性较高，而长期的监控数据的保留意义并不大。所以我们在主表上有明确的时间戳字段，使用者可以自行决定何时对保存的历史数据进行迁移。

Hydra分布式跟踪系统可以跟踪环境的数据量大小选择上文所述的三种部署方式

• 高并发，大数据量：hydra-client | Queue | hbase

• 高并发，小数据量：hydra-client | Queue | mysql

• 低并发，小数据量：hydra-client | mysql

因为是quick start，这里只介绍低并发和小数据量的情况。不过这里会详细介绍如何通过配置文件的修改来切换这三种部署方式。

• 1或多台业务系统集群机

• 1套zookeeper单点或集群机

• 1台机器部署Hydra-manager

• 1或多台机器部署Hydra-Collector

• 1台机器部署Hydra-web

• 1台数据库服务器

• Dubbo:Hydra是基于alibaba的dubbo框架基准上做的服务跟踪系统，理论上原有的Dubbo框架服务群中所有应用不需要额外的配置，皆可以平滑的接入Hydra系统。

• Zookeeper:各个服务点依赖于zookeeper来读取Hydra-manager和Hydra-collector获取数据交互路由点，来完成跟踪数据的推送和跟踪的控制。

• Mysql:跟踪数据的持久化存储。

• Tomcat:前端web应用容器

可以暂时使用master，后续版本会归并到dubbo管理端

maven项目不用多说。mvn clean install。不过不得不说的是，hydra项目中包含一些涉及数据库读写的单元测试(mysql，hbase），配置文件分别在:

• modules/hydra-manager-db/src/test/resources/mysql.properties

• modules/hydra-store/hydra-mysql/src/test/resources/mysql.properties

• modules/hydra-store/hydra-hbase/src/test/resources/hbase-site.xml

• modules/hydra-store/hydra-hbase/src/test/resources/hydra-hbase-test.xml

mysql需要创建测试用数据库和测试用表，hbase需要创建测试用表

• docs/table-hbase/initTable
  (hbase建表时可以根据hbase集群的具体情况调整域分区，涉及到table-mysql中对TB_PARA_SERVICE_ID_GEN初始化数据的设计)

• docs/table-mysql

当然对于不需要使用hbase的同学也可以自行移除modules/hydar-store/hydra-hbase。

当然用maven构建跳过测试也是可以的。使用mvn clean install -Dmaven.test.skip=true

需要打包的子项目会通过maven:assemblly插件打成tar.gz包在各自的target目录下。

hydra-client中包含hydra与dubbo的集成，以及hydra跟踪收集的相关功能。如果需要进行dubbo服务的跟踪，只需要把这个jar包放在dubbo服务的classpath下，就会自动开启跟踪功能！

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 启动：cd basedir/bin
   sh manager.sh start

4. 停止：cd basedir/bin
   sh manager.sh stop

5. 输入：cd basedir/log
   tail -f manager.log

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 启动：cd basedir/bin
   sh collector-mysql.sh start 
   (这里注意一下，如果在hydra-collector中需要发送到Queue中，则需要启动collector.sh,jar包会加载不同的配置文件。)

4. 停止：cd basedir/bin
   sh collector-mysql.sh stop

5. 输入：cd basedir/log
   tail -f *.log

1. 需要在web.xml中修改引入的配置文件为hydra-mysql.xml，注掉hydra-hbase.xml

2. 部署：scp -r target/*.war username@ip:$TOMCAT_WEBAPPS

我们模拟了两个测试场景，均是基于dubbo服务调用

场景exp1:

A --> B --> C         

即服务A调用服务B,服务B调用服务C。测试用例在modules/hydra-example/hydra-exmple-exp1/。熟悉dubbo的同学一定不会陌生。

场景exp2:

A --> B --> C1 --> E                     --> C2 --> D1 --> C1 --> E                            --> D2         

场景2很复杂，基本涵盖了对同步调用跟踪的大多数可能遇到的场景。测试用例在modules/hydra-example/hydra-exmple-exp2/。

Hydra默认使用了hydra-exmple中的两个应用场景来做，你可以在hydra-test/hydra-test-integration打包中获得应用场景。

获得tar.gz包或者zip包后，将服务分布式部署到不同的机器上，以模拟应用场景,一下介绍场景一的部署方法，场景二的部署方法类似。

hydra-test-intergration 分为windows版和linux版(默认)，见如下打包方法。

• 打包：linux: mvn package -Pruntime-env-linux
  window: mvn package -Pruntime-env-windows

• 部署: scp -r target/*.tar.gz username@ip:dirname

• 配置: cd basedir/conf
  修改 *exp1.properties

• 启动： cd basedir/bin
  cd exp1
  sh startA.sh
  cd ..
  sh startTrigger-exp1.sh start

• 停止: cd basedir/bin
  sh startTrigger-exp1.sh stop
  All.sh stop

• 输出: cd basedir/log
  tail -f *.log

以下演示安装样例：

1. 部署zookeeper单点或集群环境，以保证获得最佳SOA，zookeeper的部署请参照官方文档。

2. 部署实验场景exp1，只需要部署hydra-test-integration模块打包的tar.gz包，拷贝三份分布式部署。

3. 部署一个触发器Trigger，以激活服务的调用。

4. 部署一个Manager，以管理各个跟踪点的跟踪上下文。

5. 部署一个或者多个Collector消费机集群，以搜集来自Hydra-client推送过来的跟踪数据。

6. 部署一个web应用，已提供给前端展现应用系统服务上下文。

exp1场景说明：

有三个服务应用A、B、C和一个触发RPC调用的应用Trigger，服务调用关系为A-B-C， 每隔500s触发一个调用，持续时间为1天。

部署地址举例：

本测试针对Hydra-Client模块进行功能测试和压力测试，以便在Hydra开发的过程中及时发现重要bug和帮助优化Hydra系统性能。

本测试目前只针对Hydra-client的测试，重点关注业务系统接入Hydra和不接入Hydra前后性能影响，以保证Hydra系统接入端的低侵入性和稳定性。

针对Hydra-Client的测试，在部署上，只用部署应用场景（带Hydra_client）和Benchmark触发点，然后在应用Benchmark和应用场景上埋点分析Hydra性能。

资料来源：http://www.open-open.com/lib/view/open1370253915148.html

在上一篇文章中，我说到SOA是一个特别大的话题，不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性。虽然我们可以说SOA ≈ 模块化开发 + 分布式计算，但由于其原则的模糊性，我们仍然很难说什么应用是绝对符合SOA的，只能识别出哪些是不符合SOA的。

本篇将对8种可操作的服务设计原则进行细化的分析，作为SOA实践的参考。

服务设计原则1：优化远程调用

这里的远程调用特指RPC（Remote Procedure Call）。当然更面向对象的说法应该是远程方法调用或者远程服务调用等等。

由于SO接口通常要被远程访问，而网络传输，对象序列化/反序列化等开销都远远超过本地Object访问几个数量级，所以要加快系统的响应速度、减少带宽占用和提高吞吐量，选择高性能的远程调用方式经常是很重要的。

但是远程调用方式往往又要受限于具体的业务和部署环境，比如内网、外网、同构平台、异构平台等等。有时还要考虑它对诸如分布式事务，消息级别签名/加密，可靠异步传输等方面的支持程度（这些方面通常被称为SLA：service level agreement），甚至还包括开发者的熟悉和接受程度等等。

因此，远程调用方式往往需要根据具体情况做出选择和权衡。

以Java远程Service为例分析不同场景下，传输方式的某些可能较好选择：

• 内网 + 同框架Java客户端 + 大并发：多路复用的TCP长连接 + kryo （二进制序列化） （kryo也可以用Protostuff，FST等代替）
• 内网 + 不同框架Java客户端：TCP + Kryo
• 内网 + Java客户端 + 2PC分布式事务：RMI/IIOP （TCP + 二进制）
• 内网 + Java客户端 + 可靠异步调用：JMS + Kryo （TCP + 二进制）
• 内网 + 不同语言客户端：thrift（TCP + 二进制序列化）
• 外网 + 不同语言客户端 + 企业级特性：HTTP + WSDL + SOAP （文本）
• 外网 + 兼顾浏览器、手机等客户端：HTTP + JSON （文本）
• 外网 + 不同语言客户端 + 高性能：HTTP + ProtocolBuffer （二进制）

简单来说，从性能上讲，tcp协议 + 二进制序列化更适合内网应用。从兼容性、简单性上来说，http协议 + 文本序列化更适合外网应用。当然这并不是绝对的。另外，tcp协议在这里并不是限定远程调用协议一定只能是位于OSI网络模型的第四层的原始tcp，它可以包含tcp之上的任何非http协议。

所以，回答上面提到的问题，WebServices （经典的WSDL+SOAP+HTTP）虽然是最符合前述SOA设计原则的技术，但并不等同于SOA，我认为它只是满足了SOA的底线，而未必是某个具体场景下的最佳选择。这正如一个十项全能选手在每个单项上是很难和单项冠军去竞争的。更理想的SOA Service最好能在可以支持WebServices的同时，支持多种远程调用方式，适应不同场景，这也是Spring Remoting，SCA，Dubbo，Finagle等分布式服务框架的设计原则。

远程调用技术解释：HTTP + JSON适合SOA吗？

JSON简单易读，通用性极佳，甚至能很好支持浏览器客户端，同时也常被手机APP使用，大有取代XML之势。

但JSON本身缺乏像XML那样被广泛接受的标准schema，而一般的HTTP + JSON的远程调用方式也缺乏像Thrift，CORBA，WebServices等等那样标准IDL（接口定义语言），导致服务端和客户端之间不能形成强的服务契约，也就不能做比如自动代码生成。所以HTTP + JSON在降低了学习门槛的同时，可能显著的增加复杂应用的开发工作量和出错可能性。

例如，新浪微博提供了基于HTTP + JSON的Open API，但由于业务操作比较复杂，又在JSON上封装实现了各种语言的客户端类库，来减少用户的工作量。

为了解决这方面的问题，业界有很多不同方案来为HTTP + JSON补充添加IDL，如RSDL、JSON-WSP、WADL、WSDL 2.0等等，但事实上它们的接受度都不太理想。

另外值得一提的是，JSON格式和XML一样有冗余，即使做GZIP压缩之类的优化，传输效率通常也不如很多二进制格式，同时压缩、解压还会引入额外的性能开销。

远程调用技术解释：Apache Thrift多语言服务框架

Thrift是最初来自facebook的一套跨语言的service开发框架，支持C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, JavaScript, Node.js, Smalltalk, Delphi等几乎所有主流编程语言，具有极好的通用性。

Thrift被facebook，twitter等巨头以及开源社区都广泛使用，是非常成熟的技术。

Thrift的服务契约通过类似如下形式的IDL定义：

struct User {     1: i32 id,     2: string name,     3: string password }  service UserService {     void store(1: User user),     UserProfile retrieve(1: i32 id) } 

非常类似于C语言，易读易写，比WSDL简单明了得多。比用java之类的编程语言也更方便，有时候可以把所有相关的接口和数据结构定义放到同一个文件，发布出去的时候不用再打一个压缩包之类，甚至可以直接粘贴到文档中

Thrift还提供工具，可以基于IDL自动生成各种语言对应的服务端和客户端代码：

[lishen@dangdang thrift]thrift --gen java user.thrift [lishen@dangdang thrift]$ thrift --gen cpp user.thrift [lishen@dangdang thrift]$ thrift --gen php user.thrift [lishen@dangdang thrift]$ thrift --gen csharp user.thrift 

我认为thrift是比WebServices更简单高效的技术，是在SOA中对WebServices最具有替代性的技术之一。

远程调用技术解释：多路复用的TCP长连接

这是一种追求极致高性能高伸缩的方式，这里只做简要介绍。

比较典型的是twitter的Mux RPC协议以及google的SPDY协议，在其中多个请求同时共用同一个长连接，即一个连接交替传输不同请求的字节块。它既避免了反复建立连接开销，也避免了连接的等待闲置从而减少了系统连接总数，同时还避免了TCP顺序传输中的线头阻塞（head-of-line blocking）问题。

另外，国内比较著名的开源dubbo框架的默认RPC协议，以及业界许多小型开源RPC框架也都是类似的思路。

采用多路复用机制后，一般就要求服务器端和客户端都支持额外的类似于会话层（即OSI网络模型第六层）的语义，导致它们必须要依赖于同一套RPC框架。

其他很多RPC机制都是使用TCP短连接。即使有些RPC使用了长连接，但一个连接同一时间只能发送一个请求，然后连接就处于闲置状态，来等待接收该请求的响应，待响应完毕，该连接才能被释放或者复用。

HTTP 1.1也支持一种基于pipeline模式的长连接，其中多个HTTP请求也可共用一个连接，但它要求响应（response）也必须按照请求（request）的顺序传输返回，即FIFO先进先出。而在完全多路复用的连接中，哪个的响应先ready就可以先传输哪个，不用排队。

当然，短连接、长连接和多路复用长连接之间不存在绝对的好坏，需要取决于具体业务和技术场景，在此不详细展开了。

远程调用技术解释：Java高效序列化

最近几年，各种新的Java高效序列化方式层出不穷，不断刷新序列化性能的上限，例如Kryo，FST等开源框架。它们提供了非常高效的Java对象的序列化和反序列化实现，相比JDK标准的序列化方式（即基于Serializable接口的标准序列化，暂不考虑用诸如Externalizable接口的定制序列化），在典型场景中，其序列化时间开销可能缩短20倍以上，生成二进制字节码的大小可能缩减4倍以上。

另外，这些高效Java序列化方式的开销也显著少于跨语言的序列化方式如thrift的二进制序列化，或者JSON等等

远程调用技术解释：RMI/IIOP和分布式事务

RMI/IIOP是Java EE中标准的远程调用方式，IIOP是CORBA的协议，只有IIOP上的RMI才支持两阶段提交的分布式事务，同时提供和CORBA的互操作。

当然，严格的两阶段提交事务并不高效，还可能严重影响系统伸缩性甚至可用性等等，一般只应用在非常关键的业务中。

远程调用技术解释：Google ProtocolBuffer跨语言序列化

ProtocolBuffer是google开发的跨语言的高效二进制序列化方式，其序列化性能和thrift比较类似。事实上thrift最初就是ProtocolBuffer的仿制品。但它和thrift最大的不同是他没有自带的RPC实现（因为google没有将RPC部分开源，但有大量第三方实现）。

由于不和RPC方式耦合，反而使得ProtocolBuffer能被方便的集成进大量已有的系统和框架中。在国内它也被百度、淘宝等广泛的应用在Open API中，和HTTP搭配作为一种高效的跨平台跨组织的集成方式。

服务设计原则2：消除冗余数据

同样由于service的远程调用开销很高，所以在它的输入参数和返回结果中，还要尽量避免携带当前业务用例不需要的冗余的字段，来减少序列化和传输的开销。同时，去掉冗余字段也可以简化接口，避免给外部用户带来不必要的业务困惑。

比如article service中有个返回article list的方法

List<Article> getArticles(...)

如果业务需求仅仅是要列出文章的标题，那么在返回的article中就要避免携带它的contents等等字段。

这里经典解决方案就是引入OO中常用的Data Transfer Object (DTO)模式，专门针对特定service的用例来定制要传输的数据字段。这里就是添加一个AriticleSummary的额外数据传输对象：

List<ArticleSummary> getArticleSummaries(...)

额外的DTO确实是个麻烦，而一般OO程序通常则可直接返回自己的包含冗余的业务模型。

服务设计原则3：粗粒度契约

同样由于远程调用开销高，同时service的外部使用者对特定业务流程的了解也比不上组织内部的人，所以service的契约（接口）通常需要是粗粒度的，其中的一个操作就可能对应到一个完整的业务用例或者业务流程，这样既能减少远程调用次数，同时又降低学习成本和耦合度。

而OO接口通常可以是非常细粒度的，提供最好的灵活性和重用性。

例如，article service支持批量删除文章，OO接口中可以提供

deleteArticle(long id)

供用户自己做循环调用（暂不考虑后端SQL之类优化），但SO接口中，则最好提供

deleteArticles(Set<Long> ids)

供客户端调用，将可能的N次远程调用减少为一次。

例如，下订单的用例，要有一系列操作

addItem -> addTax -> calculateTotalPrice -> placeOrder 

OO中我们完全可以让用户自己来灵活选择，分别调用这些细粒度的可复用的方法。但在SO中，我们需要将他们封装到一个粗粒度的方法供用户做一次性远程调用，同时也隐藏了内部业务的很多复杂性。另外，客户端也从依赖4个方法变成了依赖1个方法，从而大大降低了程序耦合度。

顺便值得一提的是，如果上面订单用例中每个操作本身也是远程的service（通常在内网之中），这种粗粒度封装就变成了经典的service composition（服务组合）甚至service orchestration（服务编排）了。这种情况下粗粒度service同样可能提高了性能，因为对外网客户来说，多次跨网的远程调用变成了一次跨网调用 + 多次内网调用。

对这种粗粒度service封装和组合，经典解决方案就是引入OO中常用的Facade模式，将原来的对象屏蔽到专门的“外观”接口之后。同时，这里也很可能要求我们引入新的service参数/返回值的数据结构来组合原来多个操作的对象模型，这就同样用到前述的DTO模式。

一个简单Facade示例（FooService和BarService是两个假想的本地OO service，façade将它们的结果值组合返回）：

class FooBarFacadeImpl implements FooBarFacade {     private FooService fooService;     private BarService barService;      public FooBarDto getFooBar() {         FooBarDto fb = new FooBarDto();         fb.setFoo(fooService.getFoo());         fb.setBar(barService.getBar());         return fb;     } }   

当然，有的时候也可以不用facade和DTO，而在是FooService和BarService之外添加另一个本地service和domain model，这要和具体业务场景有关。

服务设计原则4：通用契约

由于service不假设用户的范围，所以一般要支持不同语言和平台的客户端。但各种语言和平台在功能丰富性上有很大差异，这就决定了服务契约必须取常见语言、平台以及序列化方式的最大公约数，才能保证service广泛兼容性。由此，服务契约中不能有某些语言才具备的高级特性，参数和返回值也必须是被广泛支持的较简单的数据类型（比如不能有对象循环引用）。

如果原有的OO接口不能满足以上要求，则在此我们同样需要上述的Facade和DTO，将OO接口转换为通用的SO契约。

例如原有对象模型

class Foo {    private Pattern regex; }

Pattern是Java特有的预编译好的，可序列化的正则表达式（可提高性能），但在没有特定框架支持下，可能不好直接被其他语言识别，所以可添加DTO：

class FooDto {    private String regex; }

服务设计原则5：隔离变化

虽然OO和SO都追求低耦合，但SO由于使用者范围极广，就要求了更高程度的低耦合性。

比如前述的article service，OO中可以直接返回article对象，而这个article对象在OO程序内部可能做为核心的建模的domain model，甚至作为O/R mapping等等。而在SO如果还直接返回这个article，即使没有前面所说的冗余字段，复杂类型等问题，也可能让外部用户与内部系统的核心对象模型，甚至O/R mapping机制，数据表结构等等产生了一定关联度，这样一来，内部的重构经常都会可能影响到外部的用户。

所以，这里再次对Facade和DTO产生了需求，用它们作为中介者和缓冲带，隔离内外系统，把内部系统变化对外部的冲击减少到最小程度。

服务设计原则6：契约先行

Service是往往涉及不同组织之间的合作，而按照正常逻辑，两个组织之间合作的首要任务，就是先签订明确的契约，详细规定双方合作的内容，合作的形式等等，这样才能对双方形成强有力的约束和保障，同时大家的工作也能够并行不悖，不用相互等待。因此SOA中，最佳的实践方式也是契约先行，即先做契约的设计，可以有商务，管理和技术等不同方面的人员共同参与，并定义出相应的WSDL或者IDL，然后在开发的时候再通过工具自动生成目标语言的对应代码。

对于WSDL来说，做契约先行的门槛略高，如果没有好的XML工具很难手工编制。但对于Thrift IDL或者ProtocolBuffer等来说，由于它们和普通编程语言类似，所以契约设计相对是比较容易的。另外，对于简单的HTTP + JSON来说（假设不补充使用其他描述语言），由于JSON没有标准的schema，所以是没法设计具有强约束力的契约的，只能用另外的文档做描述或者用JSON做输入输出的举例。

但是，契约先行，然后再生成服务提供端的代码，毕竟给service开发工作带来了较大的不便，特别是修改契约的时候导致代码需要重写。因此，这里同样可能需要引入Facade和DTO，即用契约产生的都是Facade和DTO代码，它们负责将请求适配和转发到其他内部程序，而内部程序则可以保持自己的主导性和稳定性。

另外，契约先行可能会给前面提到的多远程调用支持带来一些麻烦。

当然契约先行也许并不是能被广泛接受的实践方式，就像敏捷开发中“测试先行”（也就是测试驱动开发）通常都是最佳实践，但真正施行的团队却非常之少，这方面还需要不断摸索和总结。但我们至少可以认为Echo中Java2WSDL并不被认为是SOA的最佳实践。

服务设计原则7：稳定和兼容的契约

由于用户范围的广泛性，所以SO的服务契约和Java标准API类似，在公开发布之后就要保证相当的稳定性，不能随便被重构，即使升级也要考虑尽可能的向下兼容性。同时，如果用契约先行的方式，以后频繁更改契约也导致开发人员要不断重做契约到目标语言映射，非常麻烦。

这就是说SO对契约的质量要求可能大大高于一般的OO接口，理想的情况下，甚至可能需要专人（包括商务人员）来设计和评估SO契约（不管是否用契约先行的方式），而把内部的程序实现交给不同的人，而两者用Facade和DTO做桥梁。

服务设计原则8：契约包装

前述原则基本都是针对service提供端来讲的，而对service消费端而言，通过契约生成对应的客户端代码，经常就可以直接使用了。当然，如果契约本身就是Java接口之类（比如在Dubbo，Spring Remoting等框架中），可以略过代码生成的步骤。

但是，service的返回值（DTO）和service接口（Facade），可能被消费端的程序到处引用到。

这样消费端程序就较强的耦合在服务契约上了，如果服务契约不是消费端定义的，消费端就等于把自己程序的部分主导权完全让渡给了别人。

一旦契约做更改，或者消费端要选择完全不同的service提供方（有不同的契约），甚至改由本地程序自己来实现相关功能，修改工作量就可能非常大了。

另外，通过契约生成的客户端代码，经常和特定传输方式是相关的（比如webservices stub），这样给切换远程调用方式也会带来障碍。

因此，就像在通常应用中，我们要包装数据访问逻辑（OO中的DAO或者Repository模式），或者包装基础服务访问逻辑（OO中的Gateway模式）一样，在较理想的SOA设计中，我们也可以考虑包装远程service访问逻辑，由于没有恰当的名称，暂时称之为Delegate Service模式，它由消费端自己主导定义接口和参数类型，并将调用转发给真正的service客户端生成代码，从而对它的使用者完全屏蔽了服务契约，这些使用者甚至不知道这个服务到底是远程提供的的还是本地提供的。

此外，即使我们在消费端是采用某些手工调用机制（如直接构建和解析json等内容，直接收发JMS消息等等），我们同样可以用delegate service来包装相应的逻辑。

delegate service示例1：

// ArticlesService是消费端自定义的接口 class ArticleServiceDelegate implements ArticlesService {     // 假设是某种自动生成的service客户端stub类     private ArticleFacadeStub stub;      public void deleteArticles(List<Long> ids) {         stub.deleteArticles(ids);     } }   

delegate service示例2：

// ArticlesService是消费端自定义的接口 class ArticleServiceDelegate implements ArticlesService {      public void deleteArticles(List<Long> ids) {         // 用JMS和FastJson手工调用远程service         messageClient.sendMessage(queue, JSON.toJSONString(ids));     } }   

从面向对象到面向服务，再从面向服务到面向对象

总结上面的几个原则，虽然只是谈及有限的几个方面，但大致也可看出OO和SO在实际的设计开发中还是有不少显著的不同之处，而且我们没有打算用SO的原则来取代过去的OO设计，而是引入额外的层次、对象和OO设计模式，来补充传统的OO设计。

其实就是形成了这种调用流程：

• service提供端：OO程序 <- SOA层（Facade和DTO）<- 远程消费端

• service消费端：OO程序 -> Delegate Service -> SOA层（Facade和DTO 或者 其他动态调用机制）-> 远程提供端

Facade、DTO和Delegate Service负责做OO到SO和SO到OO的中间转换。

现在，可以回答Echo示例中的问题：通过“透明的”配置方式，将OO程序发布为远程Service，虽然可能较好的完成了从本地对象到远程对象的跨越，但通常并不能较好的完成OO到SO的真正跨越。

同时，透明配置方式也通常无法直接帮助遗留应用（如ERP等）转向SOA。

当然，在较为简单和使用范围确定很有限应用（比如传统和局部的RPC）中，透明式远程service发布会带来极大的便利。

另外，上面对SO的所有讨论都集中在RPC的方式，其实SO中也用message的方式做集成，它也是个大话题，暂时不在此详论了。

为什么不能放弃面向对象？

SO是有它的特定场景的，比如远程的，范围不定的客户端。所以它的那些设计原则并不能被借用来指导一般性的程序开发，比如很多OO程序和SO原则完全相反，经常都要提供细粒度接口和复杂参数类型以追求使用的使用灵活性和功能的强大性。

就具体架构而言，我认为SOA层应该是一个很薄的层次（thin layer），将OO应用或者其他遗留性应用加以包装和适配以帮助它们面向服务。其实在通常的web开发中，我们也是用一个薄的展现层（或者叫Web UI层之类）来包装OO应用，以帮助它们面向浏览器用户。因此，Façade、DTO等不会取代OO应用中核心的Domain Model、Service等等 （这里的service是OO中service，未必是SO的）。

综合起来，形成类似下面的体系结构：

理想和现实

需要特别指出的是，上面提到的诸多SO设计原则是在追求一种相对理想化的设计，以达到架构的优雅性，高效性，可重用性，可维护性，可扩展性等等。

而在现实中任何理论和原则都可能是需要作出适当妥协的，因为现实是千差万别的，其情况远比理论复杂，很难存在放之四海而皆准的真理。

而且很多方面似乎本来也没有必要追求完美和极致，比如如果有足够能力扩充硬件基础设施，就可以考虑传输一些冗余数据，选择最简单传输方式，并多来几次远程调用等等，以减轻设计开发的工作量。

那么理想化的原则就没有意义了吗？比如领域驱动设计（Domain-Driven Design）被广泛认为是最理想的OO设计方式，但极少有项目能完全采用它；测试驱动开发也被认为是最佳的敏捷开发方式，但同样极少有团队能彻底采用它。但是，恐怕没有多少人在了解它们之后会否认它们巨大的意义。

理想化的原则可以更好的帮助人们理解某类问题的本质，并做为好的出发点或者标杆，帮助那些可以灵活运用，恰当取舍的人取得更大的成绩，应付关键的挑战。这正如孔子说的“取乎其上，得乎其中；取乎其中，得乎其下；取乎其下，则无所得矣”。

另外，值得一提的是，SOA从它的理念本身来说，就带有一些的理想主义的倾向，比如向“全世界”开放，不限定客户端等等。如果真愿意按SOA的路径走，即使你是个土豪，偷个懒比浪费网络带宽重要，但说不定你的很多用户是土鳖公司，浪费几倍的带宽就大大的影响他们的利润率。

延伸讨论：SOA和敏捷软件开发矛盾吗？

SOA的服务契约要求相当的稳定性，一旦公开发布（或者双方合同商定）就不应该有经常的变更，它需要对很多方面有极高的预判。而敏捷软件开发则是拥抱变化，持续重构的。软件设计大师Martin Fowler把它们归结为计划式设计和演进式设计的不同。

计划理论（或者叫建构理论）和演进理论是近代哲学的两股思潮，影响深远，派生出了比如计划经济和市场经济，社会主义和自由主义等等各种理论。

但是，计划式设计和演进式设计并不绝对矛盾，就像计划经济和市场经济也不绝对矛盾，非此即彼，这方面需要在实践中不断摸索。前面我们讨论的设计原则和架构体系，就是将SOA层和OO应用相对隔离，分而治之，在SOA层需要更多计划式设计，而OO应用可以相对独立的演进，从而在一定程度缓解SOA和敏捷开发的矛盾。

延伸讨论：SOA和REST是一回事吗？

从最本质的意义上讲，REST（Representational State Transfer）实际是一种面向资源架构（ROA），和面向服务架构（SOA）是有根本区别的。

例如，REST是基于HTTP协议，对特定资源做增（HTTP POST）、删（HTTP DELETE）、改（HTTP PUT）、查（HTTP GET）等操作，类似于SQL中针对数据表的INSERT、DELETE、UPDATE、SELECT操作，故REST是以资源（资源可以类比为数据）为中心的。而SOA中的service通常不包含这种针对资源（数据）的细粒度操作，而是面向业务用例、业务流程的粗粒度操作，所以SOA是以业务逻辑为中心的。

但是在实际使用中，随着许多REST基本原则被不断突破，REST的概念被大大的泛化了，它往往成为很多基于HTTP的轻量级远程调用的代名词（例如前面提到过的HTTP + JSON）。比如，即使是著名的Twitter REST API也违反不少原始REST的基本原则。

在这个泛化的意义上讲，REST也可以说是有助于实现SOA的一种轻量级远程调用方式。

SOA架构的进化

前面讨论的SOA的所有问题，基本都集中在service本身的设计开发。但SOA要真正发挥最大作用，还需要不断演进成更大的架构（也就是从微观SOA过渡到宏观SOA），在此略作说明：

• 第一个层次是service架构：开发各种独立的service并满足前面的一些设计原则，我们前面基本都集中在讨论这种架构。这些独立的service有点类似于小孩的积木。

• 第二个层次是service composition（组合）架构：独立的service通过不同组合来构成新的业务或者新的service。在理想情况下，可以用一种类似小孩搭积木的方式，充分发挥想象力，将独立的积木（service）灵活的拼装组合成新的形态，还能够自由的替换其中的某个构件。这体现出SOA高度便捷的重用性，大大提高企业的业务敏捷度。

• 第三个层次是service inventory（清单）架构：通过标准化企业服务清单（或者叫注册中心）统一的组织和规划service的复用和组合。当积木越来越多了，如果还满地乱放而没有良好的归类整理，显然就玩不转了。

• 第四个层次是service-oriented enterprise架构……

总结

至此，我们只是简要的探讨了微观层面的SOA，特别是一些基本设计原则及其实践方式，以期能够略微展示SOA在实践中的本质，以有助于SOA更好的落地，进入日常操作层面。

最后，打个比方：SOA不分贵贱（不分语言、平台、组织），不远万里（通过远程调用）的提供服务（service），这要求的就是一种全心全意为人民服务的精神……

作者简介

沈理，当当网架构师和技术委员会成员，主要负责当当网的SOA实施（即服务化）以及分布式服务框架的开发。以前也有在BEA、Oracle、Redhat等外企的长期工作经历，从事过多个不同SOA相关框架和容器的开发。他的邮箱：shenli@dangdang.com

感谢马国耀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

大量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论SOA，集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等，比较适合从事实际工作的架构师和程序员来阅读。

为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观SOA的定义，并简单分析其核心原则。

亚马逊CEO杰夫•贝佐斯：鲜为人知的SOA大师

由于SOA有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点SOA的大意和作用。

按照亚马逊前著名员工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO贝佐斯就在亚马逊强制推行了以下六个原则（摘自酷壳）：

1. 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。
2. 团队间的程序模块的信息通信，都要通过这些接口。
3. 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
4. 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
5. 所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
6. 不这样的做的人会被炒鱿鱼。

据说，亚马逊网站展示一个产品明细的页面，可能要调用200-300个Service，以便生成高度个性化的内容。

Steve还提到：

Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子贝佐斯工作。不过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA驱动出来的设计会产生出平台（Platform）。

今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……

贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万世者，不足以谋一时；不谋全局者，不足以谋一隅。”

当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。

SOA漫谈：宏观与微观

SOA即面向服务架构，是一个特别大的话题。

为了方便讨论，我在此先草率的将SOA分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：

• 宏观SOA：面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考虑；架构体系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如BPM，ESB)，服务协同（choreography，更多面向跨企业集成）等等。我认为SOA本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高层次上体现出来，同时大部分SOA的业界讨论也集中在这方面。
• 微观SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。

很多业界专家都认为SOA概念过于抽象，不接地气，我认为主要是宏观SOA涉及面太广，经常需要做通盘考虑，而其中很多方面距离一般人又比较远。而在微观层面的SOA更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。

同时，宏观SOA要取得成功，通常的前提也是SOA在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）

因此，我们着眼于SOA落地的目的，着重来分析微观SOA，也算是对业界主流探讨的一个小小的补充。

SOA定义

按照英文维基百科定义：SOA是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用。

什么是“服务”？按照OASIS的定义：Service是一种按照既定“接口“来访问一个或多个软件功能的机制（另外这种访问要符合“服务描述”中策略和限制）

Service示例（代码通常以java示例）

public interface Echo {     String echo(String text); }  public class EchoImpl implements Echo {     public String echo(String text) {         return text;     } }

可能每个开发人员每天都在写类似的面向对象的Service，难道这就是在实施SOA吗？

SOA设计原则

既然SOA是设计原则（模式），那么它包含哪些内容呢？事实上，这方面并没有最标准的答案，多数是遵从著名SOA专家Thomas Erl的归纳：

标准化的服务契约 Standardized service contract 服务的松耦合 Service loose coupling 服务的抽象 Service abstraction 服务的可重用性 Service reusability 服务的自治性 Service autonomy 服务的无状态性 Service statelessness 服务的可发现性 Service discoverability 服务的可组合性 Service composability ....

这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。

但是，业界著名专家如Don Box，David Orchard等人对SOA又有各自不同的总结和侧重。

SOA不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性：例如，所谓松耦合原则需要松散到什么程度才算是符合标准的呢？这就好比一个人要帅到什么程度才算是帅哥呢？一栋楼要高到多少米才算是高楼呢？可能不同人心中都有自己的一杆秤……部分由于这些理论上的不确定因素，不同的人理解或者实施的SOA事实上也可能有比较大的差别。

浅析松耦合原则

SOA原则比较多，真正的理解往往需要逐步的积累和体会，所以在此不详细展开。这里仅以服务的松耦合为例，从不同维度来简单剖析一下这个原则，以说明SOA原则内涵的丰富性：

• 实现的松耦合：这是最基本的松耦合，即服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响到消费端，而且消费端未来还可以自由切换到该契约的其他提供方。

• 时间的松耦合：典型就是异步消息队列系统，由于有中介者（broker），所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。

• 位置的松耦合：典型就是服务注册中心和企业服务总线（ESB），消费端完全不需要直接知道提供端的具体位置，而都通过注册中心来查找或者服务总线来路由。

• 版本的松耦合：消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务的契约在升级时要尽可能的提供向下兼容性。

SOA与传统软件设计

我们可以认为：SOA ≈ 模块化开发 + 分布式计算

将两者传统上的最佳实践结合在一起，基本上可以推导出SOA的多数设计原则。SOA从软件设计（暂不考虑业务架构之类）上来讲，自身的新东西其实不算很多。

SOA原则的应用

基于SOA的原则，也许我们很难说什么应用是绝对符合SOA的，但是却能剔除明显不符合SOA的应用。

用上述标准化契约，松耦合和可重用这几个原则来尝试分析一下上面Echo示例：

• Echo的服务契约是用Java接口定义，而不是一种与平台和语言无关的标准化协议，如WSDL，CORBA IDL。当然可以抬杠，Java也是行业标准，甚至全国牙防组一致认定的东西也是行业标准。

• Java接口大大加重了与Service客户端的耦合度，即要求客户端必须也是Java，或者JVM上的动态语言（如Groovy、Jython）等等……

• 同时，Echo是一个Java的本地接口，就要求调用者最好在同一个JVM进程之内……

• Echo的业务逻辑虽然简单独立，但以上技术方面的局限就导致它无法以后在其他场合被轻易重用，比如分布式环境，异构平台等等。

因此，我们可以认为Echo并不太符合SOA的基本设计原则。

透明化的转向SOA？

修改一下上面的Echo，添加Java EE的@WebServices注解（annotation）

@WebServices public class EchoImpl implements Echo {     public String echo(String text) {         return text;     } }

现在将Echo发布为Java WebServices，并由底层框架自动生成WSDL来作为标准化的服务契约，这样就能与远程的各种语言和平台互操作了，较好的解决了上面提到的松耦合和可重用的问题。按照一般的理解，Echo似乎就成为比较理想的SOA service了。

但是……即使这个极端简化的例子，也会引出不少很关键的问题，它们决定SOA设计开发的某些难度：

• 将一个普通的Java对象通过添加注解“透明的”变成WebServices就完成了从面向对象到面向服务的跨越？
• 通过Java接口生成WSDL服务契约是好的方式吗？
• WebServices是最合适远程访问技术吗？

面向对象和面向服务的对比

面向对象（OO）和面向服务（SO）在基础理念上有大量共通之处，比如都尽可能追求抽象、封装和低耦合。

但SO相对于OO，又有非常不同的典型应用场景，比如：

• 多数OO接口（interface）都只被有限的人使用（比如团队和部门内），而SO接口（或者叫契约）一般来说都不应该对使用者的范围作出太多的限定和假设（可以是不同部门，不同企业，不同国家）。还记得贝佐斯原则吗？“团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外”。

• 多数OO接口都只在进程内被访问，而SO接口通常都是被远程调用。

简单讲，就是SO接口使用范围比一般OO接口可能广泛得多。我们用网站打个比方：一个大型网站的web界面就是它整个系统入口点和边界，可能要面对全世界的访问者（所以经常会做国际化之类的工作），而系统内部传统的OO接口和程序则被隐藏在web界面之后，只被内部较小范围使用。而理想的SO接口和web界面一样，也是变成系统入口和边界，可能要对全世界开发者开放，因此SO在设计开发之中与OO相比其实会有很多不同。

小结

在前述比较抽象的SOA大原则的基础上，我们可尝试推导一些较细化和可操作的原则，在具体实践中体现SO的独特之处。请关注本系列文章的下篇！

作者简介

沈理，当当网架构师和技术委员会成员，主要负责当当网的SOA实施（即服务化）以及分布式服务框架的开发。以前也有在BEA、Oracle、Redhat等外企的长期工作经历，从事过多个不同SOA相关框架和容器的开发。他的邮箱：shenli@dangdang.com

感谢马国耀对本文的审校。

n  通信理论

计算机与外界的信息交换称为通信。基本的通信方法有并行通信和串行通信两种。

1.一组信息（通常是字节）的各位数据被同时传送的通信方法称为并行通信。并行通信依靠并行I／O接口实现。并行通信速度快，但传输线根数多，只适用于近距离（相距数公尺）的通信。

2.一组信息的各位数据被逐位顺序传送的通信方式称为串行通信。串行通信可通过串行接口来实现。串行通信速度慢，但传输线少，适宜长距离通信。

串行通信按信息传送方向分为以下3种：

1)   单工

只能一个方向传输数据

2)   半双工

信息能双向传输，但不能同时双向传输

3)   全双工

能双向传输并且可以同时双向传输

 

n  Socket

Socket 是一种应用接口, TCP/IP 是网络传输协议，虽然接口相同, 但是不同的协议会有不同的服务性质。创建Socket 连接时，可以指定使用的传输层协议，Socket 可以支持不同的传输层协议（TCP 或UDP ），当使用TCP 协议进行连接时，该Socket 连接就是一个TCP 连接。Soket 跟TCP/IP 并没有必然的联系。Socket 编程接口在设计的时候，就希望也能适应其他的网络协议。所以，socket 的出现只是可以更方便的使用TCP/IP 协议栈而已。

引自：http://hi.baidu.com/lewutian/blog/item/b28e27fd446d641d09244d08.html

上一个通信理论其实是想说Socket(TCP)通信是全双工的方式

n  Dubbo远程同步调用原理分析

从Dubbo开源文档上了解到一个调用过程如下图

http://code.alibabatech.com/wiki/display/dubbo/User+Guide#UserGuide-APIReference

另外文档里有说明：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

Dubbo缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

• 连接个数：单连接
• 连接方式：长连接
• 传输协议：TCP
• 传输方式：NIO异步传输
• 序列化：Hessian二进制序列化
• 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
• 适用场景：常规远程服务方法调用

 通常，一个典型的同步远程调用应该是这样的：

1， 客户端线程调用远程接口，向服务端发送请求，同时当前线程应该处于“暂停“状态，即线程不能向后执行了，必需要拿到服务端给自己的结果后才能向后执行