【重磅发布】在竞争中合作的商业模式逐渐被各家云服务商认可，中国IDC圈对云计算领域200多条竞合关系进行了梳理，发布“国内主流云服务商竞争与合作关系专题”，点击进入。
中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
微软技术解决方案专家于基于云架构的性能优化专场发表了题为《微软Azure最佳实践》的演讲，现场解读了如何基于微软的Azure搭建一个动态的IT基础架构来支撑快速成长与转型的现代企业。
以下为演讲实录：
接下来由我来跟各位分享一下我们在微软Azure做的一些项目的经验。我首先说下我讲这个主题的背景，我们很多用户看到了云的发展趋势，然后就想迁移到云，为什么要迁移到云？无非大家都知道不需要一些机房，减少维护等。这样很多用户就把自己传统的应用迁移到云上面，云又分好几种服务，有IaaS、PaaS、SaaS，很多用户为了快速就用IaaS。今天讲的内容比较偏向于当你迁移到IaaS上面，我们下一步走PaaS的话，要怎么样做考量。所以这是我今天要谈的几个内容，包括我们在微软全球做过的一些案例的分享。
首先我们先看一下，从开发的角度上面，从传统的面向过程到面向组件，以及到面向服务，甚至到现在所谓的云服务，也有所谓的HTM5或者一些存储的改变，以应用到现在的云架构。从代码的一致性上面，比如说从传统的不可移植，到源代码可以移植，甚至到现在编译后可以移植以及及时运行，比如说运行的脚本上面，PHP上面，会用这些趋势做发展。开发效率上面，比如说用一些敏捷性开发做迭代，到现在的在线开发，快速的做更新、维护、管理。在运维管理方面有所谓的自动化管理以及自主管理。扩展方式大家也知道，为了应用一些资源的扩展，从垂直的扩展上面也去考虑做一些scale up的动作，最后还有快速的分发。
1、反过来我们看看微软云究竟有那些特点？
2、可以支持所谓的混合云到纯云的架构。
3、在IaaS和PaaS上面有很高的扩充性。
4、安全对于微软来说是最重要的，微软从比尔盖茨之前有提过一个可信论的计算，所以微软所有的产品在做之前一定要通过安全的验证，Azure我们在中国通过了国家三级等等的验证。
5、在商业上面有60%的财经世界500强都是跑在微软的Azure上面。
6、对于创新，微软在这方面也投入了很多新的技术，比如说微软最近也有一些AI智能的东西，高科技的东西，也有一些跟云做整合的。微软云支持微软很多最新的产品，微软以后的产品都会先在云上面发布最新的版本。
7、它是开放的、可扩展的。
微软其实有很多很多云的组件，这些云的组件我们可以去想，究竟用的是哪些。其实你可以把它分成几大类，这里列在上面的是我们最常用到的，比如说像平台、Apps、还有Storage等等，其实我们有更多的服务都在提供，大家可以参考这个网址，可以针对每一个目录所提供的东西。比如微软上周已经开始在做一些开放给最终用户去做测试，比如说N系列的虚拟机。由于这些讯息随时都在更新，所以各位有空可以去看这个网址。微软有获得一些认证，所以在全球，微软可以称之为一个安全可靠的信任云。
在考虑架构的设计时，我们先把它细化成几大块。第一块是看Azure的计算方面，其实依据CPU、内存等是会有一些限制的。比如你是IaaS走单一实例的话，微软不保证它是一个高可用性的，如果再建立一个多实例可以达到99.9%;Storage基本上可以无限的扩展，但是它扩展大的瓶颈就是IOPS，比如说等一下我们会谈到的数据库，我们设计的时候会考虑是不是要做一些切割，通常一个订阅上面可以有多个存储账户，存储账户里面会有很多的container，我们不建议把很多虚拟机都指向一个存储账户，这样很快就会把IOPS撑爆;另外就是SQL方面，因为我常常遇到究竟我走SQL IaaS还是SQL PaaS，在这块我们有很多内定的东西都帮你配置好了，你不需要去管理你的虚拟机或者是操作系统。但是，如果用到PaaS的话会有限制，比如在传统的SQL上面是会有Agent，在这里SQL PaaS就会用不了，要注意这些东西。
从可扩展性上来看，我们希望是可以水平的扩展，水平的扩展是一个Web的架构，我们会有Web Role和Worker Role 。Web Role我们通常会放页面的东西以及一些简单的运算，我们会把大部分的运算剥离开来，放到所谓的Worker Role里面，这中间是一个双耦合的架构。这样再回到我们之前，要做开发快速迭代更新的时候，就会比较方便一点，所以是一个双耦合的;可用性以及容灾，我们希望建立的是多活的方式，我们也会做一些自动扩展。将应用部署在多个站点，这也是为了扩展管理方便一点;可管理性我们有自主管理、自动管理这些。
谈了这么多，我先问一个问题，我在这里写了四点，大家觉得好的设计方式是哪一个？这种传统的设计，Web Role通过TCP去连接后端的Worker Role，这其实不是很好的设计。因为我们要考量到如果在做横向扩展的时候，会有一个问题，很多旧的请求都是在旧的机器上面，如果负载变低了，要把服务器减少的时候，假设从原来的10台变成5台，可是这时候TCP的连接是在第8台上面，因为虚拟机检回来的时候会变成你的资料不见了，所以第一个是不好的设计。
第二个，将数据库安装在两个虚拟机上面，形成主备，这是可以做的，但不是好的。因为我们希望你往PaaS上迁移，你要考虑到虚拟机的管理、操作系统的管理以及数据库的管理，还要做优化等等。所以这也不是好的答案。
第三个，session状态存储在单机内，不做复制。如果从前半段的语句理解也不是很好的设计，因为在做横向扩展再收回来的时候，因为你在本机的这个虚拟机就不见了，那你的状态就很容易丢失，这时候就不是很好的一个设计。但是，各位仔细看，它启用负载均衡的Session Affinity，这个可以管理缓存，所以这是好的一个设计。
最后一个是Web Role将用户数据存储在本地磁盘上，以提高性能。其实在Azure上面我们提供了一些快取的服务，我们也会建议你去使用快取的服务。但是这个场景大的一个问题，是因为存储在本地磁盘，对于微软的Azure，我们在定义的时候，如果你机器关机的话，存在C盘的资料会不见，这是一个很大的盲点。我们曾经遇到很多的客户，因为这部分的设计，导致他一些数据的丢失。
再来看一下，从数据结构上面，我们的建议是什么？
• 结构化数据，SQL Azure支持三块的冗余，我们会复制三份。谈这个之前我要跟各位说一个概念，在微软云里面有一个所谓的更新域，还有一个故障域。那什么叫故障域？微软会以一个基架为单位，如果坏掉的话，可能整个基架上面的机器就会出问题，这叫故障域。那什么叫更新域呢？比如说有一个应用有三份，他就会分在三个不同的基架，会自己做运算，如果其中有一个坏掉，并不会影响数据的丢失，并且如果后台做一些更新的时候，比如我在第一个基架做一些系统更新的时候，其实第二个第三个并不会影响，在30分钟之后才会去更新第二个第三个。但是，如果你在Azure上面建DV的话你就要手动配置了，所以在部署上面会比较麻烦一点。
• 我们再来说容灾，因为有三份备份，如果是IaaS你要做手动的备份。另外在可扩展性上面，可以快速的进行一些水平的扩展，如果是IaaS上面你就要手动配置集群。在易用方面基本上是零部署，你只要配置你所要的功能就可以直接使用，但是在IaaS上面你会多一个配置优化的一些动作。
• 我们再来看半结构化，其实也是一样的，都是有三份的。然后它的RPO我们可以达到所谓的30秒，也就是说当你的系统出现故障的时候，你的应用出现故障的时候，它恢复到你可用的上一个时间点，我们需要30秒来做恢复，那如果说是整个A4系统崩溃，其实我们的RTO几乎是0，所以对用户是透明的，但是如果说是一些数据容灾就没有办法做得这么高了。我们可以通过Partition做水平扩展，开源的这些也是可以做水平拓展的，同样的部署也是零部署，但还是老问题，要去做一些手动优化的动作。
• 非结构化数据，前面也是一样，基本上也都差不多。如果在所谓的扩展性上面可以通过一些CDN去做一些快速的动作，还有通过container做扩展。
所以我跟各位再分享一个小故事，大概两个礼拜前我们遇到一个客户，这个客户是比较传统的所谓的一个机房的思维。他说他们公司以前的机器都会做RAID，那我在云上用IaaS是不是也要做RAID，其实基本上不用，因为我们会提供三份的冗余，所以这要注意一下。
• 在业务逻辑上面，我们可以通过Cloud Service、Website去做扩展，IaaS上面我们可以做集群的动作。在容灾上面，我们可以用Azure本身的Traffic Manager实现灾难切换。在可扩展性基本上也都没什么差别，易用性也是一样的，会有一些配置管理的动作。
• 如果是消息队列，刚才谈到我们的应用希望是无状态的方式。但如果一个请求到Web Role的时候，它去做处理可能需要调用到后端的商业逻辑，我们可能放到所谓的Worker Role上面，那Web Role跟Worker Role怎么做沟通呢？我们希望做对列，你的请求会比较不容易丢失文件。扩展性方面，传统的消息队列就必须要手动配置集群，后面也是一样的。
• 网络方面，域名上面，我们是比较高的，是一个静态的指令。那在传统的Azure订阅，我们可以绑定五个固定的IP，如果你要更多的话必须要提出申请，如果你没有去指定IP，使用的是DHCP，我们会在所谓的DNS里面做一些指向的动作。容灾也是一样的，我们可以通过Azure的Traffic Manager，但是如果你的IP一旦指定死的话，它的扩展性就没有那么高了。
谈到这里我们来看一下具体的应用。比如说这是一个很传统的应用的网站，我在前端设计的时候用CDN节点，如果用户是一个静态请求，他基本上是走CDN进来，那如果是动态信息的话，我们就直接导进来，通过Web Role做负载均衡的动作。但是有些时候不一定要用Web Role，因为有些简单的运算放在页面上，就可以把Web Role的动作省略，直接调用后面的存储。微软的Azure在上海和北京都有数据中心，我们可以在后端配置数据同步的动作，达到这样扩展的动作。
这里有一个实际的网站，基于这样的架构去做设计的。它设计出来的结果三个月上线100万个注册用户，而且前两周有10亿的点击量，峰值是1.1亿，每天新用户大概25000个，总共使用1000个核以及500个数据库。
接下来我们来谈一下后端的数据再考量的话怎么做？第一个我们可能会做水平分割，水平分割比较适合大的数据量。它分割的要点比如说在这里依据Alexander，主要原因是我要把这些存储剥离开分散掉，避免达到IOPS的瓶颈。通常我们还会把时间放在里面，比如我一年前的资料要做归档，可能用的次数没那么多，比较适合用这种东西把它切离开来，但是最新的还是会是存储最多的。
再来看下一个是走所谓的垂直分割，垂直分割的好处是可以达到大的K需量，以及可以依据里面的资料形态，比如说有一个图形，我们可以找到对应的合适的资料形态把它做存储。
下一个是表库分离的动作，基本上跟水平分割是一样的。只不过它会通过一些Azure Cache的动作，让每一个库达到所谓的平均存储。我们刚才所谈到的如果是水平存储的话永远是最新的资料，它的负载量是大的，那这个可以减少一些IO。
这是一个基于这样子架构的客户，这个客户使用了Cache做缓存，用Worker Role做更新，8个站点，可以达到每天20亿点击，以及每秒5万请求。
我们再来看Cache这块，我们走的是HCache。我们考验Worker Role的时候有几种方式，可以说这个Worker Role是全部来做Cache的运算，这没问题;另外也可以说保留三分之一的内存做Cache，也是可以的。万一机器关掉的话这个Cache很容易就不见了，所以我们希望你通过Azure本身的Cache来达到这个，除此之外我们也提供了很多的SDK可以直接去做存储。
我们迁移到PaaS的时候要把应用做切割，理清究竟有哪些组织，然后去挑一些合适的Azure服务。
下面这个是一个我们在欧洲的一家电信公司他做的架构。他是提供了一个网盘，把所有的存储其实都是放在Azure上面，用户一开始去存储的时候，一定会连到这里，去确定他的身份是没问题的，验证过以后到后端对应的去存储他的资料，所以在这个设计上面，其实对我们的数据中心节省了很多的存储。
下面这个是一个市政的，也是在欧洲的。在ISV里面有现有的系统，市政有市政的一些内网系统，他放在公有云上面的好处就是为了跨系统去做数据交互的动作。把一些服务通过Service Bus做规划，做数据的同步，给到一些用户，可以通过WCF的方式做存储，Web Role等等，所以他开放了一些公交地铁等待时间，以及最近的交通站点的信息。
下面这是一个零售业的案例，比较偏向于一个信息发布以及内容的更新。它把一些内部的管理系统，比如说有一些库存的更新，它通过这样子把它推送到门店上面，有一些运算的话就放到Azure上面。
然后下面这是另外一个案例，就是去监控。这个车子通过Web Role做注册，合法的车主才入库，放到他的数据里面，接下来才能允许这台机器访问他的系统，这时候他就会把这个Queue的地址给到车子，所以这个车可以依据这个状态丢到数据库，然后再根据Worker Role做商业逻辑的处理，然后用户可以直接查询车的状态怎么样。
在代码开发要点，在可扩展性上面我们要考虑多个实例同时运行，因为我们要做横向扩展，所以回过头来就是要做无状态的动作。另外，可用性方面我们要考虑到在Azure上面IP地址是会变化的，如果你要固定最多只能5个，然后还有它的一些重试策略，后面我们会单独再讲。如果部署的话，因为我们把Web Role拆开，我们在做更新迭代的时候会比较方便一点。
这是一个从开发的角度去看的，比如说我们遇到服务异常的时候我们的重试策略是什么？因为遇到异常的时候会有很多的状态，我们Azure本身就提供了这方面的框架让你去做处理。一般的处理方式就是有三种，一种是定期重试，比如说在这里是间隔两秒;还有一个是递增间隔重试;另外一个是指数间隔重试，我们也把相对应的代码放在这里让各位参考。
这是应用迁移的案例，本身原来的架构是通过同步服务，通过SMTP传递信息的。在迁移过后，我们可以看到代码的变化，触发了Worker Role去做，我们把所谓的商业逻辑放到Worker Role上面。这个用户还有一个需求，因为他担心一些敏感数据，所以他希望说敏感数据放在企业内部，然后走专线的方式做存储，也改变了发邮件的处理方式，然后也更改了Session的Provider，使用了Azure的一些甄错的东西，将部分配置信息从web.config移到.cscfg。
在运维这里我们要考虑的，第一个是代码的打包，怎么样做自动化发布，我们在这里会有一些建议。监控可以采取所谓的门户监控，甚至我们也支持其他家厂商的一些产品，微软本身就是用System Center。
这是另外一个弹性伸缩模块的案例，我们在配置Web Role、Worker Role的时候，在扩展的时候可以定义一些法子，确保在符合什么样的条件的时候，我要去做扩展。所以这个案例比如说他每天早上八点到十点，因为大家刚上班请求比较多，所以他的Worker Role至少要四个，最多六个，其余时间就下来了。那Worker Role主要偏重于处理商业逻辑，所以他就偏向于CPU这里，如果超过50%的话就增加实例，如果Web Role的CPU利用率低于60%，表示他的请求就比较少，这是一个动态的，可以依据你实时的请求状况去做所谓的扩展的动作。
热门专题
