来源：至顶网服务器频道

至顶网服务器频道 07月10日 新闻消息（文/李祥敬）：2018年7月23日-25日，由中国电子学会主办，至顶网承办的以“聚力云上生态 赋能实体经济”为主题第十届中国云计算大会将在北京国家会议中心举办。

作为国内云计算大数据领域的年度盛会，中国云计算大会已经走过十个年头，而这十年也正是中国云计算产业蓬勃发展的十年。今天云计算已经深入地融入工业、交通、金融、医疗、生活服务、教育等众多行业领域，广泛地服务于实体经济，成为众多企业数字转型的核心关键技术，在中国制造向中国智造的升级、工业化和信息化的融合过程中扮演着越来越重要的作用。与此同时，云计算产业生态也得到了不断完善和丰富，并且正在成为大数据、区块链、人工智能等新一代信息技术的基础，成为企业创新创业和向数字化、网络化、智能化转型的重要力量。

当前，云计算正在变革整个IT产业。2018年，云计算产业继续向纵深发展。IaaS得到广泛认可，PaaS也成为企业业务创新的平台。在党的十九大报告中也指出，推动互联网、大数据、人工智能和实体经济深度融合。

在本届云计算大会上，云计算核心技术与实践专题论坛讲聚焦云计算核心技术的发展趋势，探讨云计算最为核心、最为关键的问题，包括部署、运维等一线最前沿的实践和趋势；云计算与容器、超融合的集成与整合；私有云与公有云的整合；以及混合云管理等。论坛核心话题包括云平台的构建和管理、公有云市场的最新发展趋势、私有云平台的部署与管理和混合云管理的最佳实践等。

在云计算快速发展的今天，国家发改委、工业和信息化部、科技部、网信办等多部委相当重视云计算的发展，并在近几年密集出台了《加快发展高技术服务业的指导意见》、《关于加强党政部门云计算服务网络安全管理的意见》、《云计算综合标准化体系建设指南》、《加快推进“宽带中国”战略、“互联网＋”行动等重大部署》、《云计算发展三年行动计划（2017-2019年）》等文件。

北京理工大学计算机学院副院长刘驰将分享云计算关键技术的研究成果，虽然目前我国云计算市场发展迅猛，但是在云计算关键技术方面，我们仍与国外有一定差距。刘驰院长专注于云计算的关键技术研究，将与我们分享最新的研究成果，相信对于提升我国云计算的自主创新能力具有重要的作用。

我国云计算产业规模快速扩大，技术创新全面推进，行业应用不断深化，云计算已经成为各行各业数字化转型的重要抓手。云计算核心技术与实践专题论坛邀请了中国铁路、飞鹤、招商银行等行业典型客户分享自身在云计算方面的最新实践，这些企业分布在制造业、金融等行业，而且这些行业是云计算重要落地的产业，具有典型的参考意义，希望通过这些嘉宾的分享，对于其它行业的客户进行上云有重要的借鉴作用。

招银云创公司（MBCloud）是招商银行的全资子公司，旨在将招商银行IT系统30年稳定运行的成功经验和金融IT的成熟度解决方案对金融同行开放，服务于社会。招银云创金融PaaS研究中心总监陈沙克将会进行《招银云创DevOps实战经历》的主题分享。金融行业不同于其它领域，是一个受到高度监管的行业。随着互联网金融业务的兴起，金融企业即要利用新技术来支撑业务的创新，同时又要满足监管的要求。面对Docker和Kubernetes等主流的技术，IT主管如何根据业务场景选择合适的技术，成为整个行业非常关注的热点。陈沙克将会介绍招银云创的PaaS平台的最佳实践，给金融行业上云提供有益的参考。

目前云计算市场深入发展，围绕云计算的新技术层出不穷。比如混合云正在被越来越多的企业所采用，其能综合利用公有云和私有云的优势，能加速产品上市、提高灵活性和可扩展性等优点，也得到越来越多的证实。在云计算核心技术与实践专题论坛上，来自众多一些云计算厂商的专家也将分享公有云平台应用部署、软件定义与云计算基础架构、混合云的管理等真知灼见。

我们期望通过这些云计算领域的一线专家、学者和云计算典型用户的最新技术、解决方案及相关经验分享，可以为企业的云计算业务运营和用户使用提供帮助，从而最大程度地释放云计算的价值，共同协手完成企业云计算信息化转型的伟大历程。

目前大会报名正在火热进行中，了解更多关于第十届云计算大会的信息请点击：http://ciecloud/2018。

在经过了最初的业务原型验证和上线运行期之后，用户业务进入了高速成长阶段。在这一阶段，业务重点不再是方向上的调整，而是在原来基础上的不断深挖、扩展；开发不仅是功能的实现，还需要兼顾成本和性能；系统不再是单体架构，还会涉及系统的扩展和多系统之间的通信；高可用也不仅是服务自动拉起或者并行扩展，还需要考虑数据可靠、对用户影响，以及服务等级协议（SLA）。

本文将以上述挑战为出发点，介绍如何通过引入新的工具、新的架构，对原有系统进行升级和优化，来更好满足这一阶段需求，并为产品的进一步发展打下基础。

关键业务需求

随着用户业务的发展，原来的功能已经无法满足要求，需要增强或者增加新的功能。在用户数和访问量达到一定规模后，原先单体架构下的简单功能，如计数和排序，将变得复杂；随着业务深入，定期举行的秒杀、促销等活动，给系统带了巨大的压力；由于数据量的飞速增长，单纯的数据库或者内存检索已经无法满足不断增加的各种查询需求；随着业务数据量的增加，产品价值的提高，如何收集系统运行数据，分析业务运行状态也成了基本需求。接下来我们聚焦这一阶段的关键业务需求，并给出相应的解决方案。

计数与排序

在单体架构下，通过简单的内存数据和对应算法就可以实现计数和排序功能。但是在大量数据和多节点协作的环境下，基于单点内存操作的实现会遇到高并发、数据同步、实时获取等问题。在这一阶段，通用方法是使用 Redis 的原生命令来实现计数和排序。

计数

在 Redis 中可用于计数的对象有字符串（string）、哈希表（hash）和有序集合（zset）3 种，对应的命令分别是 incr/incrby、hincrby 和 zincrby。

网站可以从用户的访问、交互中收集到有价值的信息。通过记录各个页面的被访问次数，我们可以根据基本的访问计数信息来决定如何缓存页面，从而减少页面载入时间并提升页面的响应速度，优化用户体验。

计数器

要实现网页点击量统计，需要设计一个时间序列计数器，对网页的点击量按不同的时间精度（1s、5s、1min、5min、1h、5h、1d 等）计数，以对网站和网页监视和分析。

数据建模以网页的地址作为 KEY，定义一个有序集合（zset），内部各成员（member）分别由计数器的精度和计数器的名字组成，所有成员的分值（score）都是 0。这样所有精度的计数器都保存在了这个有序集合里，不包含任何重复元素，并且能够允许一个接一个地遍历所有元素。

对于每个计数器及每种精度，如网页的点击量计数器和 5s，设计使用一个哈希表（hash）对象来存储网页在每 5s 时间片之内获得的点击量。其中，哈希表的每个原生的 field 都是某个时间片的开始时间，而原生的 field 对应的值则存储了网页在该时间片内获得的点击量。如图1所示。

更新计数器信息示例代码。

PRECESION = [1, 5, 60, 300, 3600, 18000, 86400] def update_counter(conn, name, count=1, now=None):

----now = now or time.time()

----pipe = conn.pipeline() ----for prec in PRECESION:

--------pnow = int(now / prec) * prec

--------hash = '%s:%s' % (prec, name)

--------pipe.zadd('http:/.....xxxxxx', hash, 0)

--------pipe.hincrby('count:' + hash, pnow, count)

----pipe.execute()

图1 网页点击计数器的实现

获取计数器信息示例代码。

def get_counter(conn, name, precision): ----hash = '%s:%s' % (precision, name)

----data = conn.hgetall('count:' + hash)

----to_return = []

----for key, value in data.iteritems():

--------to_return.append((int(key), int(value))) ----to_return.sort()

----return to_return;

当然，这里只介绍了网页点击量数据的存储模型，如果我们一味地对计数器进行更新而不执行任何清理操作的话，那么程序最终将会因为存储了过多的数据而导致内存不足，由于我们事先已经将所有已知的计数器都记录到一个有序集合里面，所以对计数器进行清理只需要遍历这个有序集合，并删除其中的旧计数器即可。

排序

在 Redis 中可用于排序的有天然有序的有序集合（zset）和键（keys）类型中的 SORT 命令，其中 SORT 命令的功能非常强大，不仅可以对列表（list）、集合（set）和有序集合（zset）进行排序，还可以完成与关系型数据库中的连接查询相类似的任务，下面分别以两个例子来介绍各自的应用。

帖子排序

论坛中的帖子通常会有各种排序方式方便用户查看，比如按发帖时间排序、按回复时间排序、按回复数量排序、按阅读量排序等，这些 TOP N 场景对响应时间要求比较高，非常适宜用有序集合（zset）来缓存排序信息，其中排序字段即为分值（score）字段。

例子

127.0.0.1:6379> zadd page_rank 10 google 8 bing 6 163 9 baidu

(integer) 4

127.0.0.1:6379> zrange page_rank 0 -1 withscores

1) "163"

2) "6"

3) "bing"

4) "8"

5) "baidu"

6) "9"

7) "google"

8) "10"

SORT 命令

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC | DESC] [ALPHA] [STORE destination]

SORT 命令提供了多种参数，可以对列表，集合和有序集合进行排序，此外还可以根据降序升序来对元素进行排序（DESC、ASC）；将元素看作是数字还是二进制字符串来进行排序（ALPHA）；使用排序元素之外的其他值作为权重来进行排序（BY pattern）。

下面代码清单展示了 SORT 命令的具体功能使用。

对列表（list）进行排序

① 顺序

127.0.0.1:6379> lpush mylist 30 10 8 19

(integer) 4

127.0.0.1:6379> sort price

1) "8"

2) "10"

3) "19"

4) "30"

② 逆序

127.0.0.1:6379> sort price desc

1) "30"

2) "19"

3) "10"

4) "8"

③ 使用 alpha 修饰符对字符串进行排序

127.0.0.1:6379> lpush website 163 kaola baidu

(integer) 3

127.0.0.1:6379> sort website alpha

1) "163"

2) "baidu"

3) "kaola"

使用 limit 修饰符限制返回结果

127.0.0.1:6379> rpush num 1 4 2 7 9 6 5 3 8 10

(integer) 10

127.0.0.1:6379> sort num limit 0 5

1) "1"

2) "2"

3) "3"

4) "4"

5) "5"

使用外部 key 进行排序

可以使用外部 key 的数据作为权重，代替默认的直接对比键值的方式来进行排序。假设现在有用户数据如表 1 所示。

表1 用户数据示例

以下将哈希表（hash）作为 by 和 get 的参数，by 和 get 选项都可以用 key->field 的格式来获取哈希表中的域的值，其中 key 表示哈希表键，而 field 则表示哈希表的域。

① 数据输入到 Redis 中

127.0.0.1:6379> hmset user_info_1 name helifu level 888

OK

127.0.0.1:6379> hmset user_info_2 name netease level 666

OK

127.0.0.1:6379> hmset user_info_3 name kaola level 777

OK

127.0.0.1:6379> hmset user_info_4 name ncr level 4444

OK

② by 选项

通过使用 by 选项，让 uid 按其他键的元素来排序。

例如以下代码让 uid 键按照 user_info_*->level 的大小来排序。

127.0.0.1:6379> sort uid by user_info_*->level

1) "2"

2) "3"

3) "1"

4) "4"

③ get 选项

使用 get 选项，可以根据排序的结果来取出相应的键值。

例如以下代码先让 uid 键按照 user_info_*->level 的大小来排序，然后再取出

user_info_ *->name的值。 127.0.0.1:6379> sort uid by user_info_*->level get user_info_*->name

1) "netease"

2) "kaola"

3) "helifu"

4) "ncr"

现在的排序结果要比只使用 by 选项要直观得多。

④ 排序获取多个外部 key

可以同时使用多个 get 选项，获取多个外部键的值。

127.0.0.1:6379> sort uid get # get user_info_*->level get user_info_*->name

1) "1"

2) "888"

3) "helifu"

4) "2"

5) "666"

6) "netease"

7) "3"

8) "777"

9) "kaola"

10) "4"

11) "4444"

12) "ncr"

⑤ 不排序获取多个外部 key

127.0.0.1:6379> sort uid by not-exists-key get # get user_info_*->level get user_info_*->name

1) "4"

2) "4444"

3) "nc"

4) "3"

5) "777"

6) "kaola"

7) "2"

8) "666"

9) "netease"

10) "1"

11) "888"

12) "helifu"

保存排序结果

127.0.0.1:6379> lrange old 0 -1

1) "1"

2) "3"

3) "5"

6) "2"

7) "4"

127.0.0.1:6379> sort old store new

(integer) 5

127.0.0.1:6379> type new list

127.0.0.1:6379> lrange new 0 -1

1) "1"

2) "2"

3) "3"

4) "4"

5) "5"

SORT 命令的时间复杂度用公式表示为 O(N+M*log(M))，其中 N 为要排序的列表或集合内的元素数量，M 为要返回的元素数量。如果只是使用 SORT 命令的 get 选项获取数据而没有进行排序，时间复杂度为 O(N)。

云环境下的实践

在云服务中实现计数和排序，可以自己使用云主机搭建 Redis 服务，也可以使用云计算服务商提供的 Redis 服务。

对于高可用和性能有要求的场景，建议使用云计算服务商提供的 Redis 服务。专业的服务商会从底层到应用本身进行良好的优化，可用率、性能指标也远高于自己搭建的 Redis 实例。同时，由于服务商提供了各种工具，开发运维成本也更低。

以网易云为例，网易云基础服务提供了名为 NCR（Netease Cloud Redis）的缓存服务，兼容开源 Redis 协议。并根据用户具体使用需求和场景，提供了主从版本和分布式集群版本两种架构。

主从服务版

如图 2 所示，主从版本实例都提供一主一从两个 Redis 实例，分别部署在不同可用域的节点上，以确保服务安全可靠。在单点故障时，主从服务通过主备切换来实现高可用。

主从版本使用较低的成本提供了高可用服务，但是也存在无法并行扩展等问题，因此适合数据量有限、对高可用有要求的产品使用。

图2 主从服务架构

分布式集群

分布式集群采用官方 Redis 集群方案，gossip/p2p 的无中心节点设计实现，无代理设计客户端直接与 Redis 集群的每个节点连接，计算出 Key 所在节点直接在对应的 Redis 节点上执行命令，如图 3 所示，详细的过程请参考后续 Redis Cluster 的相关介绍。

分布式集群采用多活模式，支持并行扩展，因此在性能、可用率方面有明显优势。但是由于分布式集群最少需要3个节点，因此成本会较高，适合对可用率、性能有较高要求的用户使用。

图3 分布式集群架构

秒杀

把秒杀服务单列出来进行分析，主要有下面两个原因。

秒杀服务的重要性：秒杀活动本身已经是很多业务推广的重要方式之一，大部分的电商类业务都会涉及这一促销方式。很多非直接秒杀的业务（如火车购票），在实际运行时也会碰到类似秒杀的场景。秒杀实际上就是在瞬时极大并发场景下如何保证系统正常运行的问题，而这种场景对很多系统都是无法避免的，因此在系统设计时，我们往往要考虑到秒杀的影响。

系统实现难度：秒杀最能考验系统负载能力，瞬间涌入平时数十倍甚至数百倍的压力，对开发和运维人员来说都是噩梦，这也为系统设计带来了巨大的挑战。针对秒杀活动的处理，是一个系统性的设计，并不是单一模块或者层面可以解决的问题，需要从系统设计整体进行考量。

处理秒杀的指导思路

秒杀的核心问题就是极高并发处理，由于系统要在瞬时承受平时数十倍甚至上百倍的流量，这往往超出系统上限，因此处理秒杀的核心思路是流控和性能优化。

流控

① 请求流控

尽可能在上游拦截和限制请求，限制流入后端的量，保证后端系统正常。

因为无论多少人参与秒杀，实际成交往往是有限的，而且远小于参加秒杀的人数，因此可以通过前端系统进行拦截，限制最终流入系统的请求数量，来保证系统正常进行。

② 客户端流控

在客户端进行访问限制，较为合适的做法是屏蔽用户高频请求，比如在网页中设置 5s 一次访问限制，可以防止用户过度刷接口。这种做法较为简单，用户体验也尚可，可以拦截大部分小白用户的异常访问，比如狂刷 F5。关键是要明确告知用户，如果像一些抢购系统那样假装提交一个排队页面但又不回应任何请求，就是赤裸裸的欺骗了。

③ Web 端流控

对客户端，特别是页面端的限流，对稍有编程知识或者网络基础的用户而言没有作用（可以简单修改 JS 或者模拟请求），因此服务端流控是必要的。服务端限流的配置方法有很多种，现在的主流 Web 服务器一般都支持配置访问限制，可以通过配置实现简单的流控。

但是这种限制一般都在协议层。如果要实现更为精细的访问限制（根据业务逻辑限流），可以在后端服务器上，对不同业务实现访问限制。常见做法是可以通过在内�...

“企业上云”是指企业通过高速互联网络，便捷地获取云服务商提供的计算、存储、软件、数据等服务，对于提高资源配置效率、降低信息化建设成本、促进共享经济发展、加快新旧动能转换，具有重要意义。

工信部信息化和软件服务业司曾明确表示，工信部计划制定支持企业上云的政策措施和操作指南。目前，以浙江、江苏等省市为首，全国已有十个省市启动企业上云政策。大众对于云安全的态度，也越来越明朗。

云计算迁移的实际情况要复杂得多，企业要想以最小的成本发挥云的最大优势，就需要首先了解云计算的旅程，以及企业的云计算转型之旅的所经历过的几个阶段。有业内人士对云安全发展持续数年的观察发现，很多企业对于云安全倾向于遵循一定的动作模式来采纳公共云计算，其态度经历的大致阶段一般如下：

一、保守阶段

这期间，CISO抗拒云计算，宣称工作负载在公共云上得不到足够的安全防护。这种行为在后来者或非常保守的公司中还时有发生，但云计算绝对在大多数大企业中起航了。换句话说，CISO不能逃避面对云计算，相反，他们必须弄清楚如何保护基于云的工作负载，不管他们喜欢与否。

二、传统安全阶段

当企业开始试水公共云计算，安全团队偏向使用原有的内部安全监视和实施工具——防火墙、代理、反病毒软件、网络分析等等，来尝试保护云工作负载。有研究表明，92%的企业一定程度上使用已有安全工具保护云安全。

这其中的问题很明显：传统安全技术是为物理设备、内部日志、以系统为中心的软件和出/入站网络流量设计的，并非公共云计算这种临时架构的专用技术。这一错位往往导致彻底的失败——32%的企业因无法有效保护云安全而弃用传统安全技术。

三、云监测阶段

一旦企业越过用现有控制措施进行云安全试验的阶段，他们便倾向于拥抱那句管理老话：“你无法管理你不能测量的东西。”这一阶段中，安全团队部署监测工具，以获得对云应用、数据、工作负载，以及所有云资产间连接的完整视图。这很有启发性，因为极少有公司对云上发生事件有着清晰准确完整的理解。

四、云亲和阶段

有了全部云资产的完整视图，智慧的安全团队就能确保进一步的安全操作适配云计算“拥有者”——软件开发人员、开发运维员工、数据中心运营。这样做的目的是为了将安全技术整合进开发模型、配置和Chef及Puppet之类编配工具中，让安全可以跟上云计算的动态本质与速度。

注意，该阶段略有点偏离纯云安全监测和策略实施，但主流企业宣称，这是建立协作和安全最佳实践的有价值偏离。

五、云安全控制阶段

自此，安全团队与云开发者和运营人员合作，向配置和运营中添加安全控制。安全倾向于从工作负载分隔开始，然后深入到更高级的控制(基于主机的安全、威胁检测、诱骗等等)。

值得指出的是，有些创新云安全工具正在桥接控制阶段和监测阶段。它们监测云，梳理所有资产，然后基于应用类型、数据敏感性或逻辑联系，建议适用的策略。这一桥梁可真正帮助加速云安全策略管理。

　六、中心策略阶段

尖端企业中才可领略到这一阶段，但这预示着未来的导向。一旦企业习惯了软件定义云安全技术的灵活性和动态本质，他们就会继续深入到：

聚合云安全工具

比如说，他们可能会选择一款工具进行微分隔和基于主机的控制。这可减少复杂性，提供中心策略和控制。

用软件定义的工具替换掉传统工具

比如，抛弃数据中心中的传统防火墙，而用软件定义的微分隔工具替代之。此种策略可在集中所有分隔策略的同时，带来数百万美元的开支节省。已有一些企业网络分隔项目开始这么做了，他们的目标就是使用软件定义的微分隔，来代替防火墙规则、基于交换机的访问控制列表(ACL)等等，可以成功地帮助企业简化安全运营，节省开支。

★★ 总结：

企业规避死胡同，直接跳到云监测阶段，或许不失为明智的做法。这可以省去数月的挫折，帮助安全团队更快地赶上云用户。在这一过程中，选择合适的云安全厂商则变得尤为重要。

重点来了!!

北京中科同向信息技术有限公司(以下简称中科同向)作为我国大数据安全、云安全、容灾备份行业研发最长、综合实力最强的企业之一，积极响应“企业上云”行动计划，多年来持续为企业提供高效的云服务，打造基于超融合架构的私有云产品——超融合系统，形成了灾备云、热备云、大数据一体机、超融合架构的云计算、大数据产品体系。

目前，公司已经形成涵盖IaaS、PaaS、SaaS三个层面的整体解决方案服务能力，致力于推动企业信息化转型，极大减少企业成本，为企业安全保驾护航!

云备份：http://heartsone/

数字化转型正在影响所有业务的垂直领域，人们处理和思考IT的方式已经发生了根本性的变化。一些成功的IT专业人员影响了企业的业务模式和策略。数字化转型正在影响所有业务垂直领域，而云计算架构师在支持下一代业务计划时必须开始思考与之前的业务模式有什么不同。

正如调研机构Gartner公司最近预测的那样，到2020年，所有IT人员都需要具备一定水平的商业智慧。“在IT领域中发展强大的商业智慧，是将IT重点从优化IT运营效率转变为推动业务效率、价值创造和增长的先决条件。” Gartner公司研究副总裁 Lily Mok在一份声明中表示，“有效的IT沟通战略的核心是能够将IT的愿景、战略和行动计划与业务明确联系起来，推动员工中期望的行为，从而提高IT绩效和业务成果。”

除了沟通之外，还需要新的管理方式来尽可能多地从员工身上获得更多价值。为了达到这一点，企业需要培训自己的员工，让他们真正像云计算架构师一样思考和行动。

无论企业是主要数据中心提供商，还是最终用户组织，都应该了解一下数据中心架构师培训技巧。

如今的IT人员不仅仅是提供专业服务或标准体系结构，他们还需要进行创新。这意味着过去适用于IT人员工作的相同规则可能不会对其职业生涯提供更多的帮助。作为云计算架构师，IT人员可以通过做培训和实施来提升技能，为自己的职业生涯增加价值，并帮助所在的公司取得进步。

1、通过技术镜头谈论商业语言

现在想像一下Snapchat或Messenger过滤器这样的技术可以做什么，他们为原始图层添加一层。从某种意义上说，云计算架构师必须考虑业务挑战，并知道如何使用适用于该情况的技术过滤器。在那里，人们必须能够讨论这些，以及他们如何改变业务流程。这意味着云计算架构师能够围绕业务需求不断应用技术架构。

2、沉浸在安全的世界

云计算架构师的商业智慧必须与对安全需求的深入理解结合起来。IDC的信息图表为弥补IT安全技能差距，描述了日益增长的风险，以及对熟练和合格的网络安全专家的需求，具体如下：

75%的企业遇到某种类型的安全事件。33%受到网络犯罪影响。63%的组织不准备作出回应。3、尽可能多地进行交叉训练

作为一个云计算架构师，需要了解并行的相关技术。如果正在创建公共云架构，请了解像OpenStack这样的平台如何帮助管理。人们永远不知道未来会怎样，组织有一天可能需要混合方法。如果可以实现规模管理，则可以帮助企业利用强大的云计算技术。云计算架构师经常关注特定的技术。例如，DevOps、虚拟化，或者只是打包和配置体系结构。如果云计算架构师具有特定的云端重点，请确保扩大云端架构。了解云服务管理(ITSM/ITOM)、自动化、集成以改进用户管理，甚至了解如何优化WAN连接。作为云计算架构师，可以有特定的关注点。但是，了解云服务的DNA使云计算架构师能够交叉训练，并为企业和其他IT团队提供有价值的反馈。

4、使用社交媒体这种强大的沟通工具

云计算架构师使用社交媒体(像Twitter这样的社交媒体工具)可以帮助其了解更多的信息，并与志同道合的架构师建立联系，拓宽对云计算设计的思路和看法。云计算架构师需要在社交媒体上提高自己的学习能力，并在市场中提升品牌。云计算架构师最好在LinkedIn上撰写博客或Facebook帖子，回复评论或者结交新朋友。

5、了解风险、设计和企业影响

云计算架构是业务的关键部分。过去，云计算架构师专注于挑战并立即尝试解决方案。那么现在的云计算架构师必须学习一个新概念：客户对风险的偏好。云计算架构师可以设计出令人惊叹的架构，但如果它不支持客户最终需要的风险模型呢?云计算架构师必须开始向客户提出一个新问题：“你有什么风险承受力?在设计此应用程序或虚拟工作负载之前，请告诉这对贵公司的影响。”

从这里开始，云计算架构师不仅要围绕其需求创建环境，还要围绕弹性进行设计。请记住，这不仅仅是一个围绕高可用性的设计。相反，需要特别关注用户、业务应用程序和特定组件的风险因素。作为一名云计算架构师，其角色是帮助客户更好地了解他们需要什么，他们能够做什么和不能没有什么，以及他们如何与其企业战略联系起来。

技术发展和进步已经成为组织业务的基本组成部分。它有助于创造更高水平的生产力，改进服务，并优化整个用户体验。但是，总需要有人帮助设计和构建这些环境。

在此给出的建议之一就是永远不要让自己被局限住。也就是说云计算架构师总是应该把握大局。每当设计云计算架构时，架构师总是要记住三点：人员、流程和技术。云计算架构师必须每次都围绕这三个概念应用到其设计中。

企业可以拥有最好的技术，但是如果不训练其员工，并且没有开发一个流程，那么这项技术将毫无用处。随着人们对新的数字化需求的转变，云计算架构师的角色将继续发生变化。因此，需要确保云计算架构师继续学习的动力，不断思考如何通过利用新技术来改善人们的生活。

来源：互联网

编辑推荐

适读人群 ：架构师、程序员及广大学习者

　　√ 微服务旨在化大而复杂为小而简单，用快速交付支撑持续创新

　　√ 被谷歌等一线IT企业采用，与容器|云计算|持续交付等热点实践密不可分

　　√ 从架构演进到原理剖析，覆盖开发、测试、部署、运维、组织变化等微服务各方面

　　√ 代码静态检查、云基础设施构建、 Docker映像构建及部署、持续交付流水线、服务日志全程实战

内容简介

　　随着RESTful、云计算、DevOps、持续交付等概念的深入人心，微服务架构逐渐成为系统架构的一个代名词。本书首先从理论出发，介绍了微服务架构的概念、诞生背景、本质特征以及优缺点；然后基于实践，探讨了如何从零开始构建**个微服务，包括Hello World API、Docker 映像构建与部署、日志聚合、监控告警、持续交付流水线等；最后，在进阶部分讨论了微服务的轻量级通信、消费者驱动的契约测试，并通过一个真实的案例描述了如何使用微服务架构改造遗留系统。全书内容丰富，条理清晰，通俗易懂，是一本理论结合实践的微服务架构的实用书籍。

　　本书不仅适合架构师、开发人员、测试人员以及运维人员阅读，也适合正在尝试使用微服务架构解耦历史遗留系统的团队或者个人参考，希望本书能在实际工作中对读者有所帮助。

作者简介

　　ThoughtWorks的首席咨询师王磊是国内较早倡导和实践微服务的先行者。王磊是开源软件的爱好者和贡献者，社区活动的参与者，《Ruby Gems开发实战》（Practical RubyGems）一书的译者，GDCR西安的组织者。他于2012年加入ThoughtWorks，为国内外诸多客户提供项目交付和咨询服务；在加入ThoughtWorks之前，曾就职过多家知名外企，具有丰富的敏捷项目实战经验。目前致力于微服务架构、高可用的Web应用以及DevOps的研究与实践。

精彩书评

　　★微服务的出现，为运维又打开了一扇窗。微服务将整个业务系统拆分为相对独立的业务模块，并强调各个微服务都可以独立测试、独立部署、独立运行；微服务之间是一种真正的低耦合，就像汽车的各个零部件，哪个坏了，拆掉换个新的就能组装上；微服务面向产品而不是项目，这样，开发、测试、运维（系统、 DBA等）可形成更稳定的“小”团队，而不是项目周期一到，各个职能解散，各回各家；微服务配以 Docker，更可谓珠联璧合。这些都对运维提出了新的机遇和挑战，熟悉 DevOps、懂 Docker、沟通能力强的综合型运维人员，市场需求和价值更加突显。

　　纵览全书，说理清楚，用清晰明了的文字，帮助大家理清了很多似是而非的概念；图文并茂，图片既清晰又贴切，语言朴实、平易近人，没有从国外翻译过来的书籍那种生硬、别扭的感觉；理论结合实际，更多融合了作者实施微服务的一线经验。是一本非常用心、又可以实际落地的好书。

　　——萧田国 开放运维联盟联合主席，高效运维社区创始人

　　★微服务架构作为 SOA在众多互联网公司中的成功新实践，是广大企业在互联网化进程中必须理解的概念。本书不仅讲述了微服务的基础理论，而且通过实例，深入浅出地涵盖了微服务构建过程中持续集成、构建、部署、持续交付以及日志聚合和运维的过程，体现了作者深厚的理论功底与扎实的实践经验，推荐阅读。

　　——徐唤春 上海商派软件有限公司技术副总裁

　　★微服务的概念初看简单清晰、容易理解，但在企业中的实际实施其实是一件很困难的事情。尤其很多计划实施微服务的公司在服务划分、 DevOps和相应的组织结构变化方面毫无经验，付出了实施的代价，却很难真正享受到微服务带来的好处。这本书总结了作者两年多在真实大型软件系统上实施微服务的经验和心得，具体指导了微服务实施在技术方面的实践，非常值得参考。

　　——杨云 ThoughtWorks首席咨询师，前支付宝资深架构师

　　★随着应用系统的不断发展演进，单体应用变得越来越大，越来越复杂，导致扩展性差，资源优化难，维护成本高等问题。为了应对这一挑战，一种更加灵活、轻便、松耦合的设计架构——微服务架构，正受到越来越多应用系统开发者的青睐，它的敏捷开发、灵活部署、易扩展等特性，使它成为解决复杂应用的一把利器。微服务架构在具体实践中是怎样实施的？它在实施过程中存在怎样的困难和挑战?作者在本书中通过理论结合实践的方式，深入浅出地阐述了微服务的本质以及如何有效地、持续地交付微服务，并给出了许多有价值的实践指导，全书内容丰富，理论结合实际，推荐阅读。

　　——薛正华博士 中国计算机学会高级会员，大数据专委会委员

目录

第 1部分 基础篇

第 1章 单块架构及其面临的挑战 ． 3

1．1三层应用架构 ． 4

1．1．1三层应用架构的发展 4

1．1．2什么是三层架构 ． 5

1．1．3三层架构的优势 ． 6

1．2单块架构 ． 6

1．2．1什么是单块架构 ． 6

1．2．2单块架构的优势 ． 7

1．2．3单块架构面临的挑战 8

1．3 小结 ． 12

第 2章 微服务架构综述 13

2．1什么是微服务架构 ． 13

2．1．1多微才够微 ． 14

2．1．2 单一职责 ． 17

2．1．3 轻量级通信 ． 17

2．1．4 独立性 ． 19

2．1．5 进程隔离 ． 20

2．2 微服务的诞生背景 ． 22

2．2．1 互联网行业的快速发展 23

2．2．2 敏捷、精益方法论的深入人心 23

2．2．3 单块架构系统面临的挑战 23

2．2．4 容器虚拟化技术 ． 23

2．3 微服务架构与 SOA 24

2．3．1 SOA概述 24

2．3．2 微服务与 SOA 25

2．4 微服务的本质 ． 26

2．4．1服务作为组件 ． 27

2．4．2 围绕业务组织团队 ． 28

2．4．3 关注产品而非项目 ． 29

2．4．4 技术多样性 ． 31

2．4．5 业务数据独立 ． 32

2．4．6 基础设施自动化 ． 33

2．4．7 演进式架构 ． 33

2．5 微服务不是银弹 ． 34

2．5．1 分布式系统的复杂度 35

2．5．2 运维成本 ． 36

2．5．3 部署自动化 ． 36

2．5．4 DevOps与组织架构 ． 37

2．5．5 服务间的依赖测试 ． 37

2．5．6 服务间的依赖管理 ． 37

2．6 小结 ． 38

第 2部分 实践篇

第 3章 构建第一个服务 41

3．1场景分析 ． 41

3．2任务拆分 ． 43

第 4章 Hello World API 45

4．1 API实现 45

4．1．1 开发语言 ――Ruby ． 45

4．1．2 Web框架――Grape ． 46

4．1．3 API的具体实现 47

4．2代码测试与静态检查 ． 50

4．2．1代码测试 ． 50

4．2．2测试覆盖率统计 ． 53

4．2．3静态检查 ． 54

4．2．4代码复杂度检查 ． 57

第 5章 构建 Docker映像 ． 61

5．1 定义 Dockerfile ． 61

5．2 配置 Docker主机 63

5．3 构建 Docker映像 64

5．4 运行 Docker容器 64

5．5 发布 Docker映像 65

5．6 小结 ． 69

第 6章 部署 Docker映像 ． 71

6．1基础设施 AWS 71

6．2基础设施自动化 ． 73

6．3 部署 Docker映像 80

6．4自动化部署 ． 81

6．5 小结 ． 84

第 7章 持续交付流水线 85

7．1持续集成环境 ． 85

7．2提交阶段 ． 87

7．3验证阶段 ． 91

7．4构建阶段 ． 91

7．5发布阶段 ． 94

7．6 小结 ． 96

第 8章 日志聚合 97

8．1 日志聚合工具简介 ． 97

8．2 Splunk的核心 ． 99

8．3 安装 Splunk索引器 100

8．4 安装 Splunk转发器 101

8．5日志查找 ． 102

8．6告警设置 ． 103

8．7 小结 ． 104

第 9章 监控与告警 ． 105

9．1 Nagios简介． 105

9．2 Nagios的工作原理 ． 107

9．3 Nagios安装． 108

9．4 Nagios的配置 ． 109

9．5 监控 products-service 111

9．6 告警 ． 113

9．7 小结 ． 114

第 10章 功能迭代 115

10．1定义模型 ． 116

10．2持久化模型 ． 117

10．3定义表现形式 ． 119

10．4 实现 API 122

10．5服务描述文件 ． 125

10．6 小结 ． 127

第 3部分 进阶篇

第 11章 微服务与持续交付 131

11．1持续交付的核心 132

11．2微服务架构与持续交付 133

11．2．1 开发 ． 133

11．2．2 测试 ． 137

11．2．3持续集成 139

11．2．4 构建 ． 139

11．2．5 部署 ． 140

11．2．6 运维 ． 143

11．3 小结 ． 144

第 12章 微服务与轻量级通信机制 ． 145

12．1同步通信与异步通信 ． 145

12．1．1 概述 ． 145

12．1．2同步通信与异步通信的选择 146

12．2远程调用 RPC ． 147

12．2．1远程过程调用的核心 147

12．2．2远程方法调用 ． 148

12．2．3远程过程调用的弊端 148

12．3 REST ． 149

12．3．1 概述 ． 149

12．3．2 REST的核心 ． 150

12．3．3 REST的优势 ． 152

12．3．4 REST的不足 ． 152

12．3．5 本节小结 ． 155

12．4 HAL ． 155

12．4．1 概述 ． 155

12．4．2 HAL的核心 156

12．4．3 HAL浏览器 160

12．5消息队列 ． 161

12．5．1 核心部分 ． 162

12．5．2 访问方式 ． 163

12．5．3消息队列的优缺点 ． 164

12．6后台任务处理系统 ． 165

12．6．1 核心部分 ． 165

12．6．2 服务回调 ． 166

12．6．3 一个例子 ． 167

12．6．4后台任务与微服务 ． 169

12．7 小结 ． 170

第 13章 微服务与测试 ． 171

13．1微服务的结构 ． 171

13．2微服务的测试策略 ． 173

13．3微服务的单元测试 ． 175

13．3．1单元测试综述 ． 175

13．3．2单元测试的内容 ． 176

13．4微服务的集成测试 ． 179

13．4．1集成测试综述 ． 179

13．4．2集成测试的实施方法 179

13．4．3集成测试的内容 ． 180

13．5基于消费者驱动的契约测试 181

13．5．1集成测试存在的弊端 181

13．5．2什么是契约 ． 183

13．5．3什么是契约测试 ． 184

13．5．4契约测试的方法 ． 185

13．5．5 Pact实现契约测试 187

13．5．6 一个例子 ． 192

13．5．7 本节小结 ． 205

13．6微服务的组件测试 ． 205

13．6．1组件测试概述 ． 205

13．6．2组件测试的方法 ． 206

13．6．3 本节小结 ． 207

13．7微服务的端到端测试 ． 208

13．7．1端到端测试概述 ． 208

13．7．2端到端测试的内容 ． 208

13．7．3 本节小结 ． 209

13．8 小结 ． 210

第 14章 使用微服务架构改造遗留系统 211

14．1背景与挑战 ． 211

14．2改造策略 ． 212

14．2．1 昀小修改 ． 212

14．2．2 功能剥离 ． 212

14．2．3 数据解耦 ． 213

14．2．4 数据同步 ． 213

14．2．5 迭代替换 ． 214

14．3快速开发实践 ． 215

14．3．1快速开发模板 ． 215

14．3．2代码生成工具 ． 217

14．3．3持续集成模板 ． 217

14．3．4一键部署工具 ． 217

14．4微服务架构下的新系统 ． 218

14．5 小结 ． 220

前言/序言

　　前言

　　一直以来，系统的架构设计就是 IT领域经久不衰的话题之一，是每个系统构建过程中极其关键的一部分，它决定了系统是否能够被正确、有效地构建。系统架构设计描述了在应用系统内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分之间相互分工、相互协作，从而为用户提供某种特定的价值。多年来，我们一直在技术的浪潮中乘风破浪，扬帆奋进，寻找更优秀的系统架构设计方式来构建系统。

　　由来

　　随着 RESTful、云计算、DevOps、持续交付等概念的深入人心，微服务架构逐渐成为系统架构的一个代名词。那么微服务是否是业界期待已久的企业架构解决方案呢？在微服务架构的实施过程中存在着怎样的困难和挑战呢？

　　在过去两年多的时间里，笔者一直在探索和实践，并助力国外某房地产互联网门户，将其复杂的业务支撑系统逐渐演进为基于微服务架构的系统。

　　这期间也经历了从微服务的理论认识，到小范围实践、迭代，再到多个基于微服务构建的项目已经成功上线的过程。在感受微服务为开发实践、测试策略、部署、运维等带来改变的同时，也切身体会到使用微服务架构，对系统灵活性、可伸缩性方面的提升，以及对团队应对变化能力的提升。

　　结构

　　鉴于此，本书从笔者实践的角度出发，首先阐述了单块架构存在的弊端以及微服务的理论基础。接着通过实践部分，让读者能够体验从零开始搭建第一个微服务的过程，包括代码静态检查、AWS基础设施构建、 Docker映像构建及部署、持续交付流水线、服务的日志聚合以及监控和告警。随后，探讨了笔者在微服务的实践过程中所积累的经验，包括基于 HAL的通信机制、消费者驱动的测试，并通过一个真实的案例，帮助读者更好地理解微服务架构所带来的灵活性、易扩展性和独立性。

　　全书分成 3部分，共 14章。

　　第 1部分为基础部分。包括第 1章和第 2章，概述了三层应用架构以及微服务架构。

　　第 2部分为实践部分。包括第 3章至第 10章，通过一个具体的实例，从头到尾介绍了一个服务从需求到实现，再到构建、部署以及运维�...

我们知道云计算主要有三种服务模式，IaaS、PaaS和SaaS，其中最底层最基础的就是IaaS。企业级私有云领域，目前IaaS领域的老大就是VMWare公司；在开源领域，最流行的IaaS框架则是OpenStack框架。

正是因为开源，才让我们可以更深入地了解云计算IaaS的运作机制。通过对OpenStack的架构的介绍，说明OpenStack是如何实现IaaS服务的。

OpenStack的起源

在云计算领域，目前Amazon占据了绝对领先的市场地位。Amazon的CEO贝佐斯靠着强硬的行政命令要求开发人员按照SOA理念来进行开发，要求所有程序模块必须要用服务接口把数据和功能开放出来。所有程序模块间的通信，必须通过这些接口进行。

可以说SOA的设计思想，构成了今天AWS云平台的技术实现基础，同样这种设计思想也被OpenStack所效仿。AWS虽好，但毕竟是商用的，随着云计算的发展，开源云平台解决方案的需求越来越强烈。

2010年7月，RackSpace和美国国家航空航天局合作合作，分别贡献出RackSpace云文件平台代码和NASANebula平台代码，OpenStack由此诞生。

AWS分层架构

OpenStack的架构

作为Amazon的追随者，OpenStack在技术架构上也与AWS有很多相似之处。OpenStack也是由几个独立的核心功能组件所构成。

分别是计算（Compute）、对象存储（ObjectStorage）、认证（Identity）、用户界面（Dashboard）、块存储（BlockStorage）、网络（Network）和镜像服务（ImageService）：

Nova：计算管理，云计算IaaS的核心，类似于Amazon的EC2（ElasticComputeCloud）。为用户提供虚拟机的管理，比如创建虚拟机或对虚拟机做热迁移。Swift：对象存储，负责对文件进行存储和检索，也包括镜像文件。Keystone：为用户提供身份验证以及OpenStack服务的授权。Horizon：为用户提供一个模块化的控制面板，基于django框架实现。Cinder：块存储服务，为虚拟机提供虚拟卷。Neutron：为虚拟机提供网络连接，允许用户创建自己的虚拟网络并连接各种网络设备。Glance：负责镜像管理，为虚拟机提供镜像。

关于每个组件的具体职责，可以参见前文《云计算IaaS管理平台的基本功能有哪些？》

OpenStack的应用

国际公有云方面，AWS、AZure都采用了自己的技术来搭建云计算平台。在国内公有云市场中，阿里云、腾讯云也都是用自有技术来搭建各自的云计算平台，没有直接利用OpenStack。

虽然在公有云市场，应用OpenStack的商业案例还不算多，但在私有云市场，基于OpenStack的项目非常多，远远多于其他的开源云计算框架,如CloudStack、Eucalyptus和OpenNebula等。

与互联网公司不同，华为倒是非常积极地推进OpenStack技术，和中国三大电信运营商们一并都是OpenStack基金会的黄金会员（GoldenMember），而且为国内外多家电信运营商都部署了基于OpenStack的公有云系统。

目前OpenStack的黄金会员主要包括传统IT企业，如Intel、NEC、Dell、VMWare等，也包括通信设备商，如华为、Ericsson、Cisco、JuniperNetworks等，也包括最新加入的国内三大运营商。相信虽然OpenStack的参与者越来越多，生态越来越完善，应用项目也会越来越多。

云计算是一种能够通过网络以便利的、按需付费的方式获取IT资源（包括网络、服务器（虚机、容器）、存储、平台、应用和服务等）并提高其可用性的模式，这些资源来自一个共享的、可配置的资源池，并能够以最省力和无人干预的方式获取和释放。

云计算：第三次IT革命

云计算发展背景

云计算特征

云计算服务类型：IaaS、PaaS、SaaS

SaaS是一种新型软件发布模式，应用软件安装在 厂商或者服务供应商那里，用户通过网络使用。Salesforce、NetSuite、Google Apps、微软Office365是典型案例。

软件开发者可以在PaaS之上直接开发新的应用，不需要购买和部署服务器和OS、数据库和中间件软件而直接部署代码即可运行客户自己的应用。Salesforce的Force、Google AppEngine和微软 Azure都是PaaS模式的典型代表。

IaaS（Infrastructure as a Service，基础架构即服务）通过互联网提供数据中心、基础架构硬件和软件资源。典型IaaS的代表产品是亚马逊的AWS（Elastic Compute Cloud）、Google的CloudEngine。

云计算部署模式

公有云：关注性价比

面向公众/政企提供的云服务，基于互联网获取和使用服务、关注盈利模式、具有强大的可扩展性和较好的规模共享经济性等。

私有云：关注信息安全

面向内部用户、通过内部或专有网络获得和使用服务，私有云的使用体验较好，安全性较高，但投资门槛高，当出现突发性需求时，私有云因规模有限，将难以快速地有效扩展。

混合云：兼顾性价比与安全

在公有云中创建网络隔离的专有云，用户可以完全控制该专有云的网络配置，同时还可以通过VPN/专线连接到内部私有云，实现公有云与私有云的连接，兼顾公有云和私有云的优点。

社区云：过渡性模式

面向一个行业（行业云）或一个地理区域范围内（园区云）提供服务，阶段性发展的产物。

欧洲核子研究中心（缩写为CERN），是全球最大的粒子物理学实验室，其存在的本质意义就是研究物质的组成和宇宙的起源。

上图为CERN的标志

CERN（读音是：[s:n]），是一个法语缩写词，意为“欧洲核子研究理事会”（法语为：Conseil Européen pour la Recherche Nucléaire），这是1952年成立的临时理事会，虽然两年后改名为欧洲核子研究中心（Organisation Européenne pour la Recherche Nucléaire），但这个缩写一直被沿用至今。

探寻物质的根本：LHC

物理学者认为：物质是由基本粒子组成的，基本粒子，又被希格斯玻色（Higgs boson）子和“上帝粒子”（God particle）。

为了证实基本粒子的存在并作深入研究，在瑞士日内瓦西部与法国接壤的边境上，CERN建造了全球最先进的LHC（Large Hadron Collider，大型强子对撞机），它被隐藏在总长约27公里的环形隧道之中。

上图为环形隧道的示意图

上图为彼得·希格斯（Peter Higgs，因成功预言“上帝粒子”存在而获2013年诺贝尔物理学奖），他身后是处于维护状态的LHC。

在环形隧道中，两束质子流相向而行，并以近光速发生碰撞，由此产生新粒子。质子的体积很小，只有10的负15次方米，因此，即便是相向而行，大多数质子也会失之交臂，撞上的几率极低：在4000万次记录中，只能发现约500次正对碰撞。

而一旦发生正对碰撞，就会引发微观的宇宙大爆炸，重现宇宙大爆炸后的瞬间状态，科学家们就从搜集到的各种数据中探求物质形成和宇宙起源的奥秘。

上图为质子-质子（pp collisions）对撞的照片

2008年9月，LHC投入试运行；2012年7月4日，在CERN的LHC中持续了7个月的质子-质子（pp collisions）对撞中，“上帝粒子”被成功发现；2013年3月14日，CERN正式宣布发现了“上帝粒子”。

2013年10月8日，诺贝尔物理学奖授予了84岁的彼得·希格斯（Peter Higgs）和80岁的弗朗索瓦·恩格勒（Franois Englert），以表彰他们成功预言了“上帝粒子”的存在。

2012年7月4日，发现“上帝粒子”后，彼得·希格斯（右）与弗朗索瓦·恩格勒（左）出席研讨会。

基本粒子的存在得以证实，宇宙的根本和起源也就有了深入探求的无限可能性。实际上，CERN的LHC已经开始了新的对撞：质子-铅离子对撞，即proton-lead (p-Pb) collisions。籍于此，物理学家可以对大爆炸之初百万分之几秒的宇宙状态有更为深入的分析和洞察。

上图为质子-铅离子(p-Pb)对撞的照片

目前，CERN的员工约有2400人，为12,500名来自世界各国的科学家提供高能物理科研的服务。

支撑高能物理研究的是海量的数据和错综复杂的应用分析环境，要构建满足这些要求的IT基础设施，云计算技术具有极高的技术契合度，是当然的首选。

CERN云架构的核心组件：Nova Cells v1

CERN是互联网的发源地，在信息技术方面，一直走在最前沿。

2013年7月，CERN的OpenStack云计算环境投入实际运行，此后，随着OpenStack版本的更新，经历了若干次升级，目前在CERN数据中心运行的是Newton版本。

尽管Nova Cell（v2）已经在Newton版本中被正式引入，新版本的技术改进和优势也正在被不断地加以宣扬，然而，CERN仍然拥有目前世界上最大规模的Nova Cell（v1）服务的实际应用环境，是解决OpenStack大规模部署的最佳案例之一。

以下，对Nova Cells v1进行简要介绍。

Nova Cells v1是为解决OpenStack大规模部署的问题而创建的，当OpenStack云环境的部署规模达到一定程度后，进一步的扩展就受到技术瓶颈的限制，这种限制主要是由数据库和消息队列而产生的。比如，随着部署规模的扩展，消息队列的性能下降得异常明显，具体而言，根据经验总结，在两百个节点的环境中，一个消息发出后，可能要20秒左右才能得到响应。

从OpenStack的Grizzly版本开始，Nova Cells项目正式推出，应用这个新的OpenStack模块，就能在保持现有OpenStack云计算环境不变的前提下，以在现有OpenStack云计算环境中添加Child Cell的技术手段，增强以Scale-Out方式大规模扩展OpenStack部署环境的能力。

Nova Cells v1的架构如下图所示：

如上图所示，使用Nova Cells v1服务，可以将计算资源的管理单位进一步细分为Cell。

不同的Cell，有着各自独立的Nova-API、Nova-Scheduler（调度）、Nova-Conductor（连接）、Nova-Compute（计算）、数据库服务（Database）、消息队列（AMQP，Advanced Message Queuing Protocol，可通过RabbitMQ等机制实现）、Nova-Cells等各项服务，在从顶层的入口API Cell开始，可以树状结构逐步向下延伸，从而实现规模的扩展。

其中，API Cell（即：Parent Cell）包含 有Nova-API 服务，用于接收用户发出的请求，并将用户请求通过Nova Cells服务以Message形式发送至指定的Cell；而Child Cell则包含除 Nova-API之外的所有Nova-*服务，实现具体的 Nova Compute节点服务；API Cell与Child Cell共享 Glance 服务，且各Cells之间（API Cell与Child Cell之间、各层级Child Cell之间）的通信均通过Nova Cells服务进行。

需要指出的是：

1）在Nova Cells v1的整体架构中，对Cells的调度与对计算节点的调度是彼此独立进行的；

2）Nova-Cells服务不仅用于不同Cell之间的消息传递，在API Cell中，Nova-Cells还为操作请求选择目标Child Cell。

综上所述，当一个创建虚拟机实例的操作请求到达API Cell时，由Nova-API接收并转发给Nova-Cells，随后，Nova-Cells选择恰当的目标Child Cell，进而将操作请求发送给此目标Child Cell的Nova-Cells服务，进行处理后再转至该Child Cell的Nova-Scheduler（主机调度服务）进行处理，随后，Nova-Scheduler处理操作请求，根据计算资源统计的相关信息，在该Child Cell中选择恰当的计算节点，进而将操作请求分发至其上以具体执行虚拟机的创建。

CERN云计算环境基于Nova Cells v1，通过全面的分布式体系架构，构建了更具弹性的OpenStack云计算环境。

到目前为止，CERN的OpenStack云计算环境“重度使用”（据CERN的IT工程师所言）Nova Cells v1。在CERN的各项科学实践中，基于Nova Cells v1的OpenStack云计算环境经受住了各种实际考验，长期、稳定和高效的运行已经证明了其所具有的实践价值。

《欧洲核子研究中心的云计算架构 》的下一篇，将对CERN的云计算架构进行简要的说明，一窥OpenStack在大规模部署背景下的成功应用案例。

在今天的改变与未来的发展预测中表明，有越来越多的企业开始主动拥抱“云”，用云计算提升自身的IT服务能力和运营效率。云计算要求基础设施具有良好的弹性、扩展性、自动化、数据移动、多租户、空间效率和对虚拟化的支持。应当高度贴合网络未来更高层次的发展趋势，随需而动的运维理念。

那么具体而言，应着重从高端服务器、高密度低成本服务器、海量存储设备和高性能计算设备等基础设施领域提高云计算数据中心的数据处理能力。那么，云计算环境下的数据中心基础设施各部分的架构应该是什么样的呢?我们来看这两点的分析：

1，云计算机房架构

为满足云计算服务弹性的需要，云计算的机房一般都将采用标准化、模块化的机房设计架构。模块化机房包括集装箱模块化机房和楼宇模块化机房。为减轻了建设方在机房选址方面的压力，帮助建设方将原来半年的建设周期缩短到两个月，而能耗仅为传统机房的50%,可适应沙漠炎热干旱地区和极地严寒地区的极端恶劣环境。楼宇模块化机房采用冷热风道隔离、精确送风、室外冷源等领先制冷技术，可适用于大中型数据中心的积木化建设和扩展。

2，云计算数据中心总体架构

云计算架构分为服务和管理两大部分。在服务方面，主要以提供用户基于云的各种服务为主，共包含3个层次：平台即服务PaaS、基础设施即服务IaaS、软件即服务SaaS.在管理方面，主要以云的管理层为主，它的功能是确保整个云计算中心能够安全、稳定地运行，并且能够被有效管理。着力于提高网络数据处理和存储能力，致力于低碳高效的利用基础资源。

更多深度文章，请关注云计算频道：https://yq.aliyun/cloud

摘要：从传统IT部署到云，人肉运维已经是过去式，云上运维该怎么开展？人工智能对于运维“威胁论”也随之袭来，如何去做更智能的活，当下很多运维人在不断思考和探寻答案。在2017云栖社区运维/DevOps在线技术峰会上，阿里云专家云登就为大家分享了云计算网络基础架构的实践和演进，精彩不容错过。

以下内容根据演讲视频以及PPT整理而成。

众所周知，云计算是以计算、存储和网络作为基础的。网络作为云计算的重要基石之一，其架构设计和演进是云计算发展的重要一环，而网络架构涉及可靠性、性能、可扩展性等多方面内容。架构是从理论设计开始的，理论设计和实践碰撞到一起，能否经得住考验，是否能够符合预期呢？厂商所提供的网络设备的高级特性真的是解决问题的银弹么？如何通过经典网络和VPC构建混合云，打通云上和云下呢？阿里云在以往的实践以及与用户的交互碰撞中遇到的问题又是如何解决的呢？本次分享中将与大家一起进行探讨。

本次分享的目录

一、常见的云计算网络架构

二、云计算网络的可靠性和故障定界

三、专有云网络的模块化

四、混合云构建的并网案例

五、云网络架构的演进趋势

下图所展示是一种常见的云计算网络集群架构。传统情况下云计算网络架构会分为三层：接入层、汇聚层和核心层。如下图所示，在接入层下面的两台交换机会进行堆叠，再下面会连接服务器，服务器一般会选择使用两个网卡进行bond之后以双上连的方式连接到2台接入交换机。在接入交换机和汇聚交换机之间也会有多条线路的连接，一般而言会存在二层或者三层的接入。对于带宽收敛比的设计而言，对于千兆集群可以采用1:1无收敛的方式，而对于万兆集群则可以使用收敛比为1:3或者1:2的方案，也可能使用无收敛的设计。从汇聚层再向上连接到核心层，一般情况会使用三层连接。

下图是另外一种比较常见的云计算网络集群架构，在Spine节点和Leaf节点之间可能会存在三层连接，而Spine节点和Core节点之间也可能会存在三层连接，这种网络架构相比于前面提到的架构而言，其扩展粒度要更细，可以细化到一组或者多组进行接入。

想必大家对于Overlay以及Underlay网络都有所了解，物理网络被称为Underlay网络，物理网络搭建完成之后应该尽量保证网络拓扑是固定的；而对于Overlay的网络而言，可以基于VXLAN技术构建VPC网络，通过软件定义和控制器的方式可以动态地构建虚拟的网络。所构建的网络可以是一个或多个虚拟的网络，可以通过云上不同的租户去定义地址规划以及路由的规划，甚至还可以提供类似于高速通道这样跨VPC之间的互通。Underlay网络的设计基本上就是前面所提到的接入-汇聚-核心架构以及Spine-Leaf架构，而对于Overlay的网络则描述的是虚拟的层面，提供的实际上是虚拟的路由器和虚拟的交换机，包括其构建出来的可以接入像SLB、RDS、ECS、OCS等云产品的VPC容器。为什么叫做Overlay呢？其实因为Overlay网络是通过VXLAN隧道的封装运行在Underlay物理网络之上的。通过Overlay逻辑网关去组织业务进行资源编排就可以构建出非常丰富的基于Overlay网络的产品。

前面主要介绍了云计算网络的一些基础概念，接下来将会针对云计算网络的可靠性以及故障定位的方式进行分享。

对于云计算平台的物理网络而言，其可靠性可以分为以下的几类：

多线路，常见二层的LACP，也就是链路聚合，对于三层则使用等价路由。设备HA，从体系结构来讲，分布式的多框、多插槽的设备能够提供多主控、多接口板这样的方式，还可以提供类似于堆叠技术和多机之间的双机热备以及多机的备份或者多机堆叠的方式，还可以提供VRRP的链路切换。探测和切换机制，实际上在网络配置交付之后，如果远端出现了问题，为了解决链路上的负载均衡以及主备切换的问题，可以引入比如NQA+Track这样的探测技术，这样可以针对静态路由的配置通过不同的优先级和NQA探测方式发现远端节点不可达的时候进行路由切换。除此之外，在探索到某台设备出现故障的时候就可以进行故障隔离，可以实现端口级或者设备级的故障隔离，保证流量可以走备份或者冗余链路进而避免流量中断，当然，这种情况下可能对于流量带宽造成一定的损失。巡检和监测，针对于Overlay和Underlay的网络会提供主动探测的机制，还有对于设备的日常日志告警的分析。设备在运行中往往会报很多的日志和告警，将这些信息收集起来之后结合云平台的业务流量可以挖掘出很多故障的可能性、已经出现的故障还有对于未来可能出现故障的预判。还可以进行流量分析，并且基于此判断云平台的网络是否出现了一些问题。

如下图所示的是常见的网络集群故障点分布图，云计算平台的网络故障点主要集中在下图中标号的几个位置：

标号1：线路故障，比如服务器上连到TOR交换机，也就是服务器上的接入网卡接入到交换机上时出现了网卡、线路或者是接入端口损坏导致线路上出现故障。同样的，从接入层到汇聚层，从汇聚层到核心层也会出现这样的线路故障。标号2：核心设备的故障，核心设备的故障可能导致跨网络端口之间的流量损失，由此造成的影响范围往往比较大。对图中所示的网络架构而言，如果流量需要跨端口进行传输，就一定需要从接入层到汇聚层再到核心层再转入另外一个POD的汇聚层。标号3：汇聚交换机的故障，一般情况下汇聚交换机采用堆叠的方式，可能会出现堆叠的分裂以及单台设备的故障，也可能出现整个端口流量上行的带宽减半或者是分裂以后导致等一些不可预期的后果，因此需要及时检测出一些故障并且及时进行隔离以及对于设备进行下线维修从而排除此类故障。标号4：接入交换机的故障，接入交换机也会发生类似于汇聚交换机的故障，堆叠分裂或者单机故障则会导致下面连接的服务器出现问题。标号5：服务器故障。标号6和7：像上述提到的堆叠出现问题造成的故障，这样的故障需要通过日常的巡检以及网络设备自身报告故障的日志告警来发现问题并及时去进行相应的处理。

以下是对于常见的网络集群故障点的详细描述：

线路故障。体现为带宽的损失，一般通过多条线路保障，三层网络设备间通常用ECMP等价路由，二层网络设备间通常采用聚合LACP，提高可靠性。在实际情况下，在公有云环境中会发现：一旦网络集群规模大了之后，堆叠出现问题的概率就会变大，与此同时，二层的广播风暴和环路出现的概率也会变大，阿里云目前在逐步地考虑去掉堆叠并且去掉二层，这也可能是未来的发展方向。这样的目的是为了简化网络并提高网络集群的可靠性。DSW故障。DSW是对于核心设备的称呼，由于所有的DSW之间不直接互联，它本身的可靠性只能依靠硬件框式分布式，多主控板（主备HA）、多接口板（上面说的多线路跨板连接）来保证单点可靠性，使用多台DSW，平时负载均衡，单台故障时互为备份链路。如果是单台DSW故障，将会影响带宽损失。PSW故障。也就是汇聚设备的故障，拓扑中有PSW堆叠和去堆叠两种情况，如果是堆叠的，单台故障，上下连线依靠跨堆叠设备的LACP或者ECMP实现业务不中断（但带宽有损失），如果不是堆叠的，参考（2）的场景。如果是单台PSW故障，影响的是下连的多组ASW带宽损失一半。ASW故障。线上很多的ASW都是堆叠的，目前阿里云也开始去堆叠，如果是堆叠的，ASW下连服务器，服务器双网卡bond接入（LACP），如果是去堆叠的ASW，服务器双网卡等价路由负载均衡。如果单台ASW故障，影响的是下连的48台服务器的带宽损失一半。未来，阿里云新构建的集群会逐渐减少对于堆叠的使用，进而提高网络设备的可靠性。其实对于网络厂商而言，他们也会对于堆叠特性进行大量的测试，但是实际上由于堆叠特性十分复杂，因为其涉及到硬件、软件、内部检测以及协议的传输备份，也就是会涉及到很多跨框、跨设备的同步以及选举机制。由于堆叠特性实现本身就非常复杂，就会导致出现问题的可能性比像路由转发这样其他简单特性更高。而在云计算场景下海量的网络设备同时运行，就进一步提升了堆叠特性出现问题的可能性，基本上就会导致出现存在堆叠的场景下可能经常会出现问题。为了解决这样的问题就需要逐步地去除堆叠和二层。服务器故障。可能体现在服务器网卡或者本身内部的应用系统的问题，服务器故障一般只会影响自己，范围比较小。PSW堆叠分裂。各自认为自己是主设备，为了减小影响，一般会配置DAD双主检测，禁掉一边，影响为整个pod的上联带宽和跨asw之间转发带宽损失一半。如果PSW堆叠整体故障，整个pod挂掉（各组ASW下的48台服务器之间仍可互通），上连不通，跨asw的互连不通。ASW堆叠分裂。类似于（6），影响为一组ASW下挂的48台服务器的互联或者上联带宽损失一半。如果ASW堆叠整体故障，该组ASW下连的48台服务器全部不通。对于（6）（7）的堆叠故障，由于厂商堆叠技术本身复杂，导致故障概率提升，再加上公共云使用的网络设备规模大，基数上去了就进一步放大出故障的概率，且影响范围大。因此网络本身的可靠性和故障位置，对于云产品来说影响的范围也是不同的，ecs之类的云产品能够打散到不同的ASW、POD甚至AZ（跨网络集群），其可靠性指标也是不同的。基本上是打散的网络设备之间的层级越高，可靠性保证越高，但同样的网络延迟也越高。

那么怎样才能够及早地发现这些故障呢？其实可以使用故障主动探测的模型。在网络集群里面，可能会选择特定的接入设备比如像服务器，将其作为主动探测的机器，其探测的目标就是网络设备下面的其他服务器。

建立的第一个简单故障主动探测的模型如下：

一个TOR下面所有物理服务器（例如48台）都同时出现大量丢包-->TOR交换机故障。个别物理服务器出现丢包-->服务器负载问题/TOR交换机端口队列打满。到某个机房的大量物理服务器同时出现大量丢包-->汇聚交换机/核心交换机故障。到某个机房的大量物理服务器出现少量概率丢包->汇聚交换机/核心交换机的个别端口问题。每个机房最少只需要1台机器作为探测源，部署对业务网络影响小，ICMPping之类的只能做Layer3的探测。

依照上述的故障主动探测模型就可以简单地判断网络出现故障的范围。

建立的第二个简单故障主动探测的模型如下：

通过选择不同位置的服务器作为探测源或者探测目标，发现不同层次的故障位置，多轮次组合。要求每台服务器运行agent，并接受外部控制器指令，动态调整探测策略，可建立TCP连接并测试。可以针对overlay和underlay网络进行探测，更容易模拟实际应用的业务流量特征，支持Layer4探测、时延计算。

第二个故障主动探测模型在服务器内部会增加一些代理Agent，安装代理之后可以做到对于4到7层的探测，可以探测出TCP连接的情况以及其延迟和性能速率。同样的，探测模型也可以组合出不同的探测方式，在了解网络架构的拓扑之后就可以探测位于同一组接入交换机下面的两台或者多台服务器，也可以探测位于不同的核心交换机或者汇聚交换机下面的多台服务器。通过这种建模方式就可以知道当前延迟高或者丢包的场景下，网络的问题到底出现在什么位置。

上述提到的是网络体现在本身体系结构上的可靠性，比如分布式设备、支持主备HA、支持双机热备或者多机堆叠以及其他一些高级特性，这些都是从网络设备本身的角度而言的。除此之外，通过线路带宽的设计保证收敛比以及负载均衡，以此来保证云计算网络的可靠性。而通过日常的巡检和探测能够及时地发现故障，并在故障发生之后及时了解故障发生的具体原因并提供故障定位的方式，进而提高云平台网络的可靠性。

上述这些都是在公有云网络上的实践，对于专有云而言，又会存在什么样的差别呢？其实对于专有云而言，更多地会对其进行模块化的设计。公有云一般而言是可规划的，可以对于未来集群的规模、建设的地域以及网络架构的选择等进行规划。而对于专有云而言，客户的需求往往不能够规划出来，不同的客户所需要的业务的场景和诉求往往是不同的，这些在网络设备的选型、已有设备的利旧使用以及对于云平台功能的裁剪上都会有所体现，所以专有云与公有云上的的网络设计就存在较大的差别。

下图是专有云网络架构图，一个很明显的特点就是专有云网络会分成几个区域，最上面的是外部接入区，外部接入区包含了阿里云和ISP或者用户骨干网出口的链接以及在其上进行安全防护的云盾。专有云网络架构图中间的DSW和下部的PSW则属于DC区，也就是网络架构的核心区域。图中右面的综合接入区分为了两个部分，一部分是阿里云所提供的负载均衡、VPC网关以及OPS相关的接入，另外一部分则是CSW，实际上就是客户的VPC专线接入区，阿里云的专有云客户会有一些原来的物理网络需要与云上的VPC进行网络打通，一般会通过VPC的专线接入交换机的综合交换机接入进来。也就是说专有云网络的每一个模块都有一个相对独立的设计，所有的模�...