《Windows Azure Platform 系列文章目录》   　　对于传统的自建数据中心，从底层的Network，Storage，Servers，Virtualization，中间层的OS，Middleware，Runtime，最上层的Application，Data，都需要企业进行管理。这就好比农村自建房。 　　对于公有云平台，一般分为三种类型: IaaS, PaaS和SaaS。 　　Microsoft Azure平台属于IaaS和PaaS范畴。   　　1.　　IaaS 　　对于用户来说，底层的Network, Storage, Server, Virtualization微软Azure都已经准备就绪了。用户只需要把应用部署到Azure IaaS即可，日常只需要管理中间层的OS，Middleware，Runtime和最上层的Application，Data。 　　Azure支持的操作系统为 　　-　　Windows : Server 2008 R2, Server 2012, Server 2012 R2 　　-　　SQL Server：SQL Server 2008 R2, SQL Server 2012 SP1, SQL Server 2014 RTM  (Web, Standard, Enterprise) 　　-　　Linux: 　　　　Ubuntu (12.04 LTS, 12.10, 13.10, 14.04 LTS), 　　　　CentOS (6.5), 　　　　SUSE (SUSE Linux Enterprise Server 11 SP3) 　　对于IaaS来说，OS以上部分的管理和维护都需要用户来管理。这样的缺点是:比如说用户现在使用Windows Server 2012 R2，将来微软release了Windows Server 2012 R2 SP1，需要用户进行手动升级。 　　 　　2.　　PaaS 　　在PaaS里，OS，Middleware，Runtime都是由Microsoft Azure来管理。PaaS强调的是提供平台能力，而不需要关心OS，Middleware，Runtime。即客户只需要告诉Microsoft Azure提供运行Application的能力，无论是.NET的能力，Java的能力，PHP的能力等等。企业可以非常方便的将应用程序部署到Microsoft Azure。 微软提供Azure SDK包含的开发平台： 　　-　　.NET 　　- 　　Java 　　-　　PHP 　　-　　Node.js 　　-　　Python 　　-　　Ruby 　　从迁移难度来说，从IDC机房迁移到Azure PaaS难度要比IaaS大，因为PaaS需要进行一定的代码修改。 　　我个人的建议是先让用户将本地的应用迁移到Azure的IaaS平台，享受云计算带来的便利性和可靠性；然后在IaaS平稳运行的前提下，将部分应用迁移至PaaS平台。   　　3.　　SaaS 　　Microsoft Azure不是SaaS平台。 　　SaaS是提供给用户完整的软件解决方案，开箱即用的。最终用户无需了解该软件解决方案背后是部署在哪家云计算供应商，背后的平台是使用IaaS还是PaaS服务。 　　微软的Office 365就是非常典型的SaaS服务。类似的像Salesforce.com这样的解决方案也是提供SaaS服务。 　　对于那些ISV厂商来说，传统交付软件的方式是需要经过以下几步： 　　-　　在客户现场首先部署硬件服务，包括安装服务器，网络，防火墙，电源等 　　-　　安装软件，包括操作系统，数据库软件，运行时软件 　　-　　安装应用软件 　　可以看到，这样的软件交付流程，其实包括了硬件的交付和软件的交付。对于ISV厂商来说，不仅仅需要维护软件的可用性，而且需要维护底层的硬件服务器。 　　ISV厂商采用了微软的Microsoft Azure公有云服务之后，可以采用 　　-　　IaaS，将底层的Network, Storage, Server, Virtualization全部交付给Microsoft Azure 　　-　　PaaS，将底层的Network, Storage, Server, Virtualization和中间层的OS，Middleware，Runtime交付给Microsoft Azure 　　ISV厂商只要专注于软件的开发和升级就可以。其他硬件服务器的运维等等工作，都交付给微软Azure来处理就可以了。 　　通过这样对应用程序的改造和升级，那些传统的ISV厂商就可以利用微软的公有云服务，提供给自己的客户SaaS的服务。 　　 　　   　　Microsoft Azure所提供的服务 　　注意：本篇仅介绍Azure China提供的服务。Azure平台是一个更新的平台，每个月都会有新的feature release，笔者尽最大可能更新文档，但本文不代表Azure 平台提供的最终服务内容。 　　按照Microsoft Azure的业务价值和典型的业务场景，Microsoft Azure的各个服务组件分类如下： 　　 服务类型 计算服务 数据服务 应用服务 网络 服务详细 l   虚拟机 l   Web Site(预览) l   云服务 l   SQL Database l   存储 l   服务总线 l   Notification Hubs l   Active Directory l   CDN(预览) l   Scheduler l   虚拟网络  　　注：以上内容会随着Microsoft Azure平台变化而增加，想了解Azure提供的所有服务，请参考www.windowsazure.cn。 　　基于以上这些服务组件，用户可以灵活的构建自己的IT架构和应用环境。 　　 　　一. 存储服务 　　Azure存储服务是云端的文件存储服务，简单理解是用户可以将本地的文件、图片、照片等二进制文件保存在云端的存储服务中。 　　在传统的IDC数据中心，存储是某个机器名、或者保存在某个服务器的某个磁盘下，或者是某个存储的网络位置。 　　在Azure存储服务，其实是一个http / https的网络路径，可以进行权限控制。Azure存储服务并不依赖于任何一个IP地址或者是网络路径。 　　 　　存储服务本身支持99.9%的SLA，它提供三种高可用: 　　1)本地数据中心的三重冗余 (Local Redundant Storage, LRS)。比如客户可以选择将存储服务在同一个数据中心做三重冗余，比如在上海的数据中心做三重冗余。任意一个保存在上海存储服务的文件，都有一个主备份和一个子备份。 　　 　　比如客户上传了10 GB电影，其实Azure存储服务在同一个数据中心保存了30GB。但是Azure收费只会收取用户实际上传的10GB费用。 　　对于LRS，事务在同一个数据中心的三重冗余是同步执行的。   　　2)跨数据中心的三重冗余 (Geo Redundant Storage, GRS) 　　细心的用户会发现，微软在国外和国内的数据中心建设都是成对的，比如北京数据中心和上海数据中心。这是因为微软充分考虑了异地冗余的能力。在北京和上海数据中心之间会有专线连接，这个专线是内网数据中心之前数据同步专用的。 　　 　　比如用户在上海数据中心(主要位置)创建了存储账号，并且开启了跨数据中心同步的能力。当用户往上海数据中心上传10GB电影，该电影文件不仅在上海数据中心做了三重冗余，在北京的数据中心(辅助位置)也会做三重冗余，文件一共做了六重冗余。举个例子，即使上海数据中心因为地震、战争、洪水完全被摧毁了，用户的数据还是安全的保存在北京的数据中心，文件真正做到了万无一失。 　　 对于主要位置的数据中心来说，事务是异步从主要位置发送到辅助位置的。 　　下表显示了当前的主要位置和辅助位置的信息: 　　 主要位置 辅助位置 中国东部 中国北部 中国北部 中国东部  　　 　　 　　GRS的RPO 和RTO是多少? 　　恢复点目标 (RPO)：在 GRS 和 RA-GRS中，存储服务将数据从主要位置异步跨地域复制到辅助位置。发生重大区域性灾难，需要进行故障转移时，未进行跨地域冗余复制的最新增量变化可能会丢失。这种潜在数据丢失的分钟数称为 RPO（即数据可以恢复到的时间点）。我们的 RPO通常不会超过 15分钟，不过目前尚无 SLA涉及跨地域冗余复制需要多长时间。 　　 　　恢复时间目标 (RTO)：另一个需要了解的指标是 RTO。这指的是进行故障转移以及执行故障转移后使存储帐户恢复联机所需的时间。进行故障转移所用的时间包括： 　　(A)调查并确定能否在主要位置恢复数据或是否应该进行故障转移所需要的时间 　　(B)通过更改 DNS条目实现帐户故障转移的时间 　　我们非常重视保护您的数据，所以如果有任何恢复数据的可能，我们将暂缓故障转移，并尽量恢复主要位置的数据。将来我们计划提供一个 API，使客户可以在帐户级别触发故障转移，从而使他们能够自己控制 RTO，但目前尚不可用。 　　 　　3)读取访问地域冗余 (Read Access – Geo Redundant Storage, RA-GRS) 　　简单的来说，如果用户在上海数据中心(主要位置)创建了存储账号，并且开启了RA-GRS，事务就会异步的复制到北京的数据中心。RA-GRS提供了对复制到北京数据中心(辅助位置)的”只读”访问权，实现对存储账户的更高读取可用性。 这样用户可以指定对于Azure Storage的访问是指向上海数据中心(主要位置，还是北京数据中心(辅助位置)，提高读取的高可用性。 启用该功能后，在主要区域无法读取数据时，可使用辅助位置读取更高可用性。该功能为”选择使用”，要求存储账户进行跨地域冗余复制。   　　举个例子，假设我在上海数据中心(主要位置)创建了Azure Storage，Storage Name为leizhangstorage，并且开启了读取访问地域冗余 (Read Access – Geo Redundant Storage, RA-GRS)。 　　(A)我就可以通过http://leizhangstorage.blob.core.chinacloudapi.cn 访问主要位置的Azure Storage Account。 　　(B)然后还可以通过http://leizhangstorage-secondary.blob.core.chinacloudapi.cn 访问次要位置的Azure Storage Account 　　(C)在发生上海数据中心(主要位置)无法读取数据的时候，可以使用辅助位置的数据读取来提供高可用性。 　　参考资料: http://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/04/introducing-read-access-geo-replicated-storage-ra-grs-for-windows-azure-storage.aspx http://blog.csdn.net/azurechina/article/details/22749157   　　Azure存储服务提供三种不同类型的存储服务: Blob, Table, Queue。 　　 　　1. Blob 　　Blob就是保存大型二进制对象，比如用来存储文件、图片、文档等二进制格式的文件。 　　Blob分为两种类型： 　　(1)Block Blob 　　这种类型适合存储二进制文件，支持断点续传，可以最大以4M为一个区块单位，单一文件最大可以存储200GB，且区块不会连续存储，可能会在不同的存储服务器分块存放。为了适应文件的上传和下载而专门进行了优化。 Block可以通过2种方式创建。不超过64MB的Block Blobs可以通过调用PutBlob操作进行上传。大于64M的Block Blobs必须分块上传，且每块的大小不能超过4MB。 　　(2)Page Blob 　　这类存储优化了随机访问。它会在存储区中划分一个连续的区域供应用程序存放数据，可以用来存放VHD，单一文件最大可以存储1TB。   　　Blob服务由Blob本身以及其收纳容器(Container)构成，容器可以视为一般本机上的文件夹。 　　你可以通过REST API来访问Blob 　　http://<accountname>.blob.core.chinacloudapi.cn/<containername>/<blobname> 　　accountname表示哪个Azure存储账号下的资源，是全局唯一的。 blob.core.chinacloudapi.cn表示azure china blob存储资源，是固定的。 containername表示容器的名字，可以认为是访问某一文件夹下的资源 blobname表示我要访问的资源名称，你可以认为是一个mp3文件，或者是一个jpg文件。 　　 　　举例说明： 　　我保存在leizhangstorage存储账号下，containername为photo，blobname为myphoto.jpg。则这个URL地址为： 　　http://leizhangstorage.blob.core.chinacloudapi.cn/photo/myphoto.jpg   　　我保存在leizhangstorage存储账号下，containername为vhd，blobname为myvm.vhd。则这个URL地址为： 　　http://leizhangstorage.blob.core.chinacloudapi.cn/vhd/myvm.vhd   　　注意Container的命名规则 　　-　　containername只能是一级目录，没有办法在containername下再设置下一级别containername 　　-　　必须以英文或数字开头，且名称内只能有英文、数字及dash(-) 　　-　　不能以dash(-)开头或结尾，dash(-)不能连续出现 　　-　　所有的英文的字符必须是小写 　　-　　长度为3-63之间   　　Blob的命名规则 　　-　　除了url的保留字符以外，其他的字符组合都可以使用 　　-　　长度为1-1024个字符 　　-　　尽量避免以dot(.)或者是forward slash(/)结尾。否则会造成Blob Service误判。   　　2.Table 　　这里的Azure Storage Table是非关系型数据表，不能与SQL Server的Table相混淆。用户可以近似认为Azure Storage Table是NoSQL。 　　 　　Azure Table中的每一行记录就是一个Entity，单个Entity的最大容量是1M。 Azure Table中表的所有记录最大容量是200TB，每个Azure Table都必须有Partition Key和Row Key。Azure Table属性最多有255个。 Partition Key的值可以设置记录的物理位置。 　　在Azure Table中的2条数据，如果Partition Key值相同，则表示这2条数据存储的物理位置是相同的； 　　如果Partition Key不同，则表示这2条数据可能存储在同一台物理介质上，或者不同的2台物理介质上。如下图: 　　 　　Table使用的场景，比较适合于日志文件存储，或者是需要非关系型数据库的场景。   　　3.Queue 　　Queue，队列，是一种先到先服务(First-Come, First-Serve)，或者称为FIFO(先入先出)的存储服务。队列可以是字符串或者是最长64KB的二进制数据。 在Azure PaaS中有一个非常重要的概念叫Web Role/Worker Role。Queue作为Web Role/Worker Role沟通的重要的桥梁。 有关Azure PaaS平台的Web Role/Worker Role的内容，笔者会在接下来一章进行详细的介绍。   　　存储服务的性能指标 　　用户在选择使用Azure存储服务之前需要关心的一个方面是它的性能指标，也就是说，该存储服务是否能够满足用户日常的使用需求，同时是否能够满足用户访问峰值的情况。以下是一个存储账号的最大性能指标。 　　(1)一个存储账号的最大数据存储量是100TB 　　(2)一个存储账号最大的Transaction是每秒处理5000次(包括Blob，Queue和Table) 　　(3)一个存储账号最大的带宽是每秒钟传输3GB数据 　　以上性能指标是当前Microsoft Azure存储服务所能提供的最大性能指标，所以在应用程序运行过程中，用户实际上能获得的性能指标会低于该指标。 　　 　　Windows Azure使用数据划分来提高数据访问性能和弹性伸缩。所以用户也应该尽量使用数据划分来把数据分散存储到多个服务器上以获得尽可能高的数据访问性能。每个数据划分的最大性能指标如下： 　　(1)对于单个Blob，每秒钟可以传输60MB数据 　　(2)对于单个Table Partition Key，每秒钟可以处理500个实体记录 　　注意，这只是单个Table Partition Key的性能指标，不是单个Azure Table。因此如果一个Azure Table能够有好的Partition设计，可以提高性能。 　　(3)对于消息队列，每秒钟可以处理500个消息   　　如果应用程序已经达到单个存储账号的最大性能指标，则可以考虑以下策略来进一步提高性能。 　　(1)对于Blob，可以考虑使用CDN来将经常访问的数据缓存到离用户最近的Edge Server来减少数据传输的时间。 　　(2)对于Table，可以考虑设计Partition Key，尽量把数据分散存储到多个地方 　　(3)对于Queue，可以考虑把多个消息集中到一个消息中或使用多个消息队列   　　存储服务安全性 　　Windows Azure存储服务会分配给用户两个访问密钥：主访问密钥和辅助访问密钥。 　　该访问密钥是256个字节的字符串，用户使用该访问密钥来验证每一个对Windows Azure存储服务的数据访问请求。 　　它的工作流程如下： 　　(1)用户首先构建数据访问请求，该数据访问请求可以是读Blob、写Entity到Table中或者使用Queue 　　(2)用户使用访问密钥通过加密算法对数据访问请求进行数字签名 　　(3)该数字签名包含在数据访问请求的标头部分(HTML Header)，然后数据访问请求发送到Windows Azure存储服务 　　需要注意的是，我们在申请存储账号时系统生成了两个访问密钥：一个是主访问密钥，另一个是辅访问密钥。两个访问密钥的功能相同都可以访问数据。之所以有两个是为了方便用户切换访问密钥。比如，在通常情况下用户使用主访问密钥，如果一旦主访问密钥被泄露，用户可以把主访问密钥在最短的时间内失效(重新生成一个新的主访问密钥)，然后切换到使用辅访问密钥。用户不需要为此修改代码，而只需要更改服务配置文件即可，同时更新服务配置文件也没有宕机时间。此外，另外一种有效的做法是应用程序代码可以先使用主访问密钥来访问数据，如果验证失败，代码自动使用辅访问密钥，这样用户在切换访问密钥时就不会有宕机时间了。 　　为了进一步提高对Blob数据访问控制的灵活度，Windows Azure数据存储服务还提供了另外一种叫做Shared Access Signature的数据访问控制方式。使用Shared Access Signature，管理员可以为其他用户生成一个临时的数据访问请求，该临时数据访问请求包含有效的数字签名，所以它可以通过数据验证。该临时数据访问请求也包含该用户可以访问哪些数据和操作权限等信息，而且该临时数据访问请求只会在指定时间内有效。这样管理员既可以允许其他用户访问数据，又不会泄露访问密钥。 　　 　　需要注意的是，我们在申请存储账号时系统生成了两个访问密钥：一个是主访问密钥，另一个是辅访问密钥。两个访问密钥的功能相同都可以访问数据。之所以有两个是为了方便用户切换访问密钥。比如，在通常情况下用户使用主访问密钥，如果一旦主访问密钥被泄露，用户可以把主访问密钥在最短的时间内失效(重新生成一个新的主访问密钥)，然后切换到使用辅访问密钥。用户不需要为此修改代码，而只需要更改服务配置文件即可，同时更新服务配置文件也没有宕机时间。此外，另外一种有效的做法是应用程序代码可以先使用主访问密钥来访问数据，如果验证失败，代码自动使用辅访问密钥，这样用户在切换访问密钥时就不会有宕机时间了。 为了进一步提高对Blob数据访问控制的灵活度，Windows Azure数据存储服务还提供了另外一种叫做Shared Access Signature的数据访问控制方式。使用Shared Access Signature，管理员可以为其他用户生成一个临时的数据访问请求，该临时数据访问请求包含有效的数字签名，所以它可以通过数据验证。该临时数据访问请求也包含该用户可以访问哪些数据和操作权限等信息，而且该临时数据访问请求只会在指定时间内有效。这样管理员既可以允许其他用户访问数据，又不会泄露访问密钥。   　　二.计算服务 　　计算服务可以近似认为是CPU+RAM的计算能力 　　Windows Azure提供三种不同的计算服务：Web Site，Cloud Service和Virtual Machine。   　　1.Web Site 　　Web Site比较适合轻量级的计算能力。 　　Web Site的特点在于快速、轻松部署一个高度可扩展的云环境。使用您所选择的语言和开源应用程序，比如WordExpress，FTP，Git或者TFS，并轻松集成Windows Azure的服务，比如SQL数据库，缓存，CDN和存储。 　　但是Web Site只能提供比较基本的Windows Azure功能，比如Application和Data。但是更加高级的功能，比如Startup Task，Native Code，Virtual Network等功能，它是不支持的。 Azure Web Site提供四种不同的计算模式： 　　(1)免费(Free) 　　-　　如果在免费(Free)模式下，客户的计算资源是和其他用户共享的，不是独享的。也就是说，Free Web Site的资源是和别的用户共享CPU。 　　-　　一个Azure账户最多只能创建10个类型为Free的Azure Web Site。 　　-　　在Free模式下，一个Azure Web Site最多能使用的存储大小为1GB 　　-　　在Free模式下，Azure Web Site不支持横向扩展功能 　　-　　在Free模式下，Azure Web Site是没有SLA保障的   　　(2)共享(Shared) 　　-　　如果在共享(Free)模式下，客户的计算资源是和其他用户共享的，不是独享的。也就是说，Shared Web Site的资源是和别的用户共享CPU。 　　-　　一个Azure账户最多只能创建100个类型为Shared的Azure Web Site。 　　-　　在Shared模式下，一个Azure Web Site最多能使用的存储大小为1GB 　　-　　在Shared模式下，Azure Web Site支持横向扩展功能，且横向支持最多6个共享实例 　　-　　在Shared模式下，Azure Web Site是没有SLA保障的   　　(3)基本(Basic) 　　-　　如果在基本(Basic)模式下，客户的计算资源是独享的 　　-　　Basic模式下，独享的计算资源有三种类型 　　　　(A)Small : 1Core/1.75GB RAM 　　　　(B)Medium : 2Core/3.5GB RAM 　　　　(C)Large: 4Core/7GB RAM 　　-　　一个Azure账户可以创建无限多个类型为Basic的Azure Web Site 　　-　　在Basic模式下，一个Azure Web Site最多能使用的存储大小为10GB 　　-　　在Basic模式下，Azure Web Site支持横向扩展功能，且横向支持最多3个独享的实例 　　-　　在Basic模式下，Azure Web Site支持99.9%的SLA 　　 　　(4)标准(Standard) 　　-　　如果在标准(Standard)模式下，客户的计算资源是独享的 　　-　　Standard模式下，独享的计算资源有三种类型 　　　　(A)Small : 1Core/1.75GB RAM 　　　　(B)Medium: 2Core/3.5GB RAM 　　　　(C)Large: 4Core/7GB RAM 　　-　　一个Azure账户可以创建无限多个类型为Standard的Azure Web Site 　　-　　在Standard模式下，一个Azure Web Site最多能使用的存储大小为50GB 　　-　　在Standard模式下，Azure Web Site支持横向扩展功能，且横向支持最多10个独享的实例 　　-　　在Standard模式下，Azure Web Site支持99.9%的SLA 　　有关于Azure WebSite的技术指标，请参考： 　　http://azure.microsoft.com/en-us/pricing/details/web-sites/ 　　   　　2. Cloud Service 　　Azure PaaS比较适合新开发部署的应用。 　　注意Azure PaaS是non-persist VM，也就是非持久化虚拟机。这里的非持久化，意思是azure只对客户开发的代码负责， 　　Azure Cloud Service从广义角度来说有两种：PaaS Web Role/Worker Role和IaaS的DNS，这里我主要介绍PaaS的Web Role/Worker Role。 　　 　　Azure PaaS允许开发人员，基于微软提供Azure SDK for .NET，Java，PHP，Node.js，Python，Ruby等，将应用程序部署到Azure PaaS平台。 PaaS的Web Role/Worker Role是非常重要的概念。 　　 　　通过利用Web Role，开发人员可以利用Web Role来部署HTTP/HTTPS的应用程序，包括ASP.NET, PHP(FastCGI), JSP等或者是基于HTTP的WCF应用程序等的Web应用程序。Web Role直接与外界进行通信。 　　Worker Role可以简单理解成Windows上的Windows Service服务，它是一个无用户界面的应用程序角色，默默地在后台运行，开发人员可以利用Worker Role来处理不需要用户界面的大量计算逻辑。 　　Web Role可以通过Queue的方式(也就是Azure Storage Queue)，向Worker Role发送一串消息，让Worker Role执行用户自己需要的逻辑。   　　为什么微软要有Worker Role？它的好处在哪里？在这里我举个例子您就能明白，比如我们有一个信息管理系统，需要上传Excel文档来进行解析和处理，从软件设计的角度来说有2种方法来解决 　　(1)在ASP.NET应用程序里新建个upload control,在upload control里面写函数：一旦Excel文件上传完毕，则在.cs文件执行对于Excel的处理工作。 　　但这样会有一个缺点，如果Excel文件里包含的内容非常大的话，需要时间来处理这些内容，所以前台的ASP.NET的页面会停滞或者无响应。虽然我们也可以通过增加progressbar或者loading图片来增强用户的体验，但是从软件设计上来说不是最好的。 　　(2)前端还是用原来的处理方式，使用upload control。服务器端增加一个Windows Service，时序的查询某一个文件夹，一旦发现前端页面上传了一个Excel文件，则Windows Service执行处理Excel的工作。这样前端的页面会及时的响应并且得到更好的用户体验。 　　但是这还是有一个缺陷，前端的页面和windows service是一对一的关系，如果附件上传的数量很大的话会出现Windows Service来不及处理的情况。 　　(3)有了Worker Role，我们可以让一个ASP.NET页面后端有多个Worker Role来进行分布式的计算，是一对多的关系，能够有效的利用云上的计算资源，Worker Role可以处理高负载的数据访问。   　　采用第三种方法的好处有以下两点： 　　(1)异步处理，Web Role只响应客户端的HTTP请求，进行快速的响应。而Worker Role在后端处理Web Role发送过来的消息(Queue)，两者是松耦合的。 　　(2)Web Role和Worker Role的关系是多对多的，比如我可以在Web Role的配置中，设置 Instance Count为10。如下图: 　　 　　而在Worker Role的配置中，设置Instance Count为3 　　 　　这样的好处在于，前端有10台Azure Cloud Service Web Role Instance响应客户端HTTP的请求，而后端有3个Worker Role Instance来处理复杂的业务逻辑。 　 这种架构就好比一个餐厅，里面有10个服务员(Web Role)和3个厨师(Worker Role)。 -          服务员(Web Role)只负责招待客人(响应客户端请求)，并将客人的点菜信息通过队列消息交给厨房(Queue.AddMessage()) -          厨师(Worker Role)读取点菜信息(Queue.GetMessage)，随后负责烧菜做饭(进行后端逻辑)，当饭菜准备完毕后，则删除点菜信息。 -          如果前端压力过大(客户端请求过多)，则Web Role可以横向扩展 -          如果后端压力过大(后端逻辑处理过多)，则Worker Role也可以横向扩展 -          这种松耦合，多对多的关系非常适合企业级应用架构   　　　　 　　可以看到，Web Role和Worker Role进行通信的重要途径是经过Azure Storage Queue，了解Queue对于Azure PaaS架构设计非常重要。 　　相比于下面介绍的IaaS，azure PaaS的好处，总结下来有以下几点： 　　(1)面向应用，而不是面向IT基础设施。微软作为云计算供应商，让用户将更多的精力放在构建优秀的软件架构上，而不必考虑底层的问题，例如网络、操作系统、虚拟化等IT基础设施上。又比如：PaaS(Platform as a Service)允许云计算供应商能够自动地升级操作系统，安装补丁；而在IaaS云平台上，升级操作系统、安装补丁的操作需要用户手动的去进行配置和升级，及时性、可靠性都不高。采用了PaaS平台后，云计算供应商和软件开发者能够各司其职，将注意力放到自己领域内的问题上。 　　(2)弹性。Microsoft Azure具有Worker Role和Web Role。Web Role能够响应前端事件，而Worker Role能够响应Web Role发送过来的请求。这样的架构在保证前端快速响应的同时，又使得云计算架构更加弹性。   　　Azure PaaS平台支持 　　(1)多种开发语言，包括.NET, Java, PHP, Node.js, Python等 　　(2)Azure PaaS的虚拟机类型，除了A0以外，都是独享的，支持以下8种虚拟机大小 　　 实例名称 CPU RAM A0 Share 768MB A1 1 Core 1.75GB A2 2 Core 3.5GB A3 4 Core 7GB A4 8 Core 14GB A5 2 Core 14GB A6 4 Core 28GB A7 8 Core 56GB 　　(3)Azure PaaS还支持虚拟机的动态横向扩展，如10台类型为A7(8Core/56GB)的实例做并行计算处理。   　　3. Azure Virtual Machine (IaaS) 　　IaaS (infrastructure as a Service)在云计算分类上，面向于IT基础设施及服务，让用户能够部署和运行自己需要的操作系统、中间件和运行时。对于传统的商业软件来说，迁移到IaaS平台上所花费的时间、精力相比PaaS而言要小很多。IaaS更加适合传统的商业软件。 　　Azure Virtual Machine虚拟机是以VHD格式进行保存的，并且保存在Azure Storage Blob。因为Azure Storage支持本地冗余、异地冗余、读取访问地域冗余，Azure Virtual Machine从存储的角度来说，已经提供了存储的高可用。 　　另外，Microsoft Azure支持Hyper-V托管的虚拟机上传至Azure云端进行托管。这样对于那些已经在企业内部实施微软Hyper-V虚拟化技术的企业来说，可以快速将企业内部的Hyper-V虚拟机直接上传至Azure，加快迁移的上线时间。 　　Azure Virtual Machine支持的类型为： 　　 虚拟机类型 CPU RAM 临时磁盘 外挂磁盘数量 IOPS A0 Share 768MB 20GB 1 500 A1 1 1.75GB 70GB 2 2 * 500 A2 2 3.5GB 135GB 4 4 * 500 A3 4 7GB 285GB 8 8 * 500 A4 8 14GB 605GB 16 16 *500 A5 2 14GB 135GB 4 4 * 500 A6 4 28GB 285GB 8 8 * 500 A7 8 56GB 605GB 16 16 * 500 　　举例来说，Microsoft Azure单个节点支持的最大计算能力为A7，即8Core/56GB的计算能力。可以外挂16块磁盘，每块磁盘的最大容量为1TB，即外挂16TB的存储。支持的最大的IOPS为16*500=8000 　　请注意：以上Azure虚拟机CPU和内存是固定搭配的，不可按照用户的想法随意更改。   　　对于临时磁盘来说，该磁盘容量是与虚拟机类型有关。对于A7类型的虚拟机来说，该临时磁盘容量是605G。 　　对于Windows操作系统来说，该临时磁盘的盘符为D盘，且该盘符名为(Temporary Storage)。　　这块临时磁盘的优势是：它的IOPS非常高，延迟非常低。　　但是这块磁盘也有缺点：它不是持久化磁盘，也就是说，如果客户将文件保存在这块磁盘上，会有丢失文件的风险。这块磁盘其实是Azure Virtual Machine虚拟机所在物理机的磁盘，如果Azure Virtual Machine被重置了，或者漂移了，那保存在D盘的文件就会丢失。　　我们建议将一些非关键的数据(允许丢失的数据)，比如SQL Server的TempDB，临时文件等保存在Temporary Storage里。　　http://blogs.msdn.com/b/wats/archive/2013/12/07/understanding-the-temporary-drive-on-windows-azure-virtual-machines.aspx 　　 　　 　　Azure Virtual Machine支持的虚拟机操作系统为： 　　-　　Windows : Server 2008 R2, Server 2012, Server 2012 R2 　　-　　SQL Server：SQL Server 2008 R2, SQL Server 2012 SP1, SQL Server 2014 RTM  (Web, Standard, Enterprise) 　　-　　Linux : 　　　　Ubuntu (12.04 LTS, 12.10, 13.10, 14.04 LTS), 　　　　CentOS (6.5), 　　　　SUSE (SUSE Linux Enterprise Server 11 SP3) 　　 　　如何选择Microsoft Azure计算服务 　　如果我是一个企业级的用户，面对这三种不同的计算能力，我应该选择哪一种服务，将现有的企业应用迁移到Microsoft Azure云计算平台上呢？ 　　从Microsoft Azure提供的三种服务的区别，如下图： 　　 　　从上图中我们不难发现，在Microsoft Azure服务平台里，Web Site特点是： 　　(1)在Windows Azure上构建高度可扩展的Web站点。 　　(2)快速、轻松部署一个高度可扩展的云环境，并且可以从很小的规模开始。 　　(3)使用您所选择的语言和开源应用程序，比如WordExpress, FTP, Git或者TFS，并轻松集成Microsoft Azure的服务，比如SQL 数据库，缓存，CDN和存储。 　　(4)Web Site的特点在于快速部署，只能提供比较基本的Windows Azure功能，比如Application和Data。但是更加高级的功能，比如Startup Task，Native Code，Virtual Network等功能，它是不支持的。   　　Web Site比较适合 　　(1)现代的Web应用程序。包括客户端脚本，服务器端脚本和数据库的应用程序。并且可以横向扩展。 　　(2)连续开发。直接从源代码库使用Git或者Team Foundation进行部署。 　　(3)使用开源应用程序。你可以直接使用开源的应用程序，比如WordPress等。   　　Cloud Service的特点如下: 　　(1)在Windows Azure上简历或扩展您的企业应用程序。 　　(2)利用丰富的PaaS环境，创建高度可用的，可扩展的应用程序和服务。支持高级的多层架构，自动部署和弹性计算。通过Windows Azure PaaS，可以为全世界的客户提供强大的SaaS解决方案。 　　(3)通过Virtual Network，可以将本地局域网的网络与Windows Azure公有云网络做连接。这样就可以让企业网络享受公有云带来的高度弹性计算和互操作性，同时也保证网络安全。   　　Cloud Service比较适合 　　(1)多层的应用程序，每层都可以自我扩展。使用Web Role和Worker Role，Web Role可以响应前端的显示，而将复杂的业务放在后端进行处理。 　　(2)先进的管理。如果您的应用程序需要管理员权限、远程桌面访问或以提升的权限运行代码，您可以使用Cloud Service。 　　(3)私有云+公有云。你可以使用Windows Azure Connect与Azure公有云进行点对点的连接，或者使用Azure Virtual Network将企业内网或者私有网络与到公有云相互连接。   　　Virtual Machine的特点如下： 　　(1)提供IaaS的服务。不仅仅支持Windows，而且支持Linux操作系统。 　　(2)轻松地在几分钟内部署和运行Windows Server和Linux虚拟机，迁移运行负载，而且无需改变现有的代码。对于基于Windows OS的应用来说，可以将其部署到Hyper-V里做成VHD文件，然后直接上传到Windows Azure上面进行部署和托管。 　　(3)支持Virtual Network，将您的局域网企业应用与公有云直接连接，享受云计算带来的便利性。   　　Virtual Machine的特点如下: 　　(1)支持Windows或者Linux。你可以将现有的基于Windows或者Linux的应用快速迁移到Windows Azure。 　　(2)支持更多的服务应用程序。可以在Windows Azure使用SQL Server, MySQL，MongoDB，SharePoint应用程序。 　　(3)支持将已有应用程序迁移到公有云。你可以将持久化的非关系型数据保存到Windows Azure VHD里。     　　三.SQL Database (SQL Azure) 　　请注意，这里的SQL Database不同于传统的SQL Server 2008 R2，SQL Server 2012，SQL Server 2014。 　　微软在Azure Virtual Machine中提供与传统SQL Server一致的虚拟机服务。请参考Azure Virtual Machine相关内容。   　　这里介绍的SQL Database，是PaaS的SQL Server服务。在以前的版本称为SQL Azure，后来改名为Windows Azure SQL Database，简称SQL Database。 　　为了与传统的SQL Server做区分，笔者个人习惯使用老的SQL Azure来称呼Windows Azure SQL Database，请各位读者注意。   　　一般情况下，如果企业内部需要新建一个数据库服务，需要经历采购硬件、网络布线、安装操作系统、安装驱动程序、安装数据库软件等过程，整个过程显得漫长而繁琐，并且后期需要IT人员来维护数据库服务器。 　　如果客户订阅了SQL Azure服务的用户，可以方便快速使用SQL Azure服务而不需要采购任何硬件和安装软件。对于用户来说，SQL Azure就像是一个在Internet上已经创建好的SQL Server服务器，由微软托管和运维，并且部署在微软上海和北京的数据中心。用户只要简单的选择离自己物理位置最近的数据中心，就能立刻快速的享受到SQL Azure的服务。 　　SQL Azure能够提供的服务： 　　(1)传统SQL Server的功能，如表、视图、函数、存储过程和触发器等。 　　(2)数据同步：提供数据同步和聚合功能。 　　(3)管理：为SQL Azure提供自动配置、计量、计费、负载均衡、容错和安全功能。 　　(4)数据访问：定义访问SQL Azure的不同编程方法，目前SQL Azure支持TDS，包括ADO.NET，Entity Framework，ADO.NET Data Service，ODBC，JDBC和LINQ客户端。   　　SQL Azure Database与传统SQL Server Database有什么不同? SQL Azure Database提供由微软托管的在云端的高可用性，可扩展性，多租户数据库服务。SQL Azure Database可以实现自主管理，供应与更简便的多数据库部署。开发者不必安装或管理任何软件。对于企业使用者来说，因为没有安装硬件和部署软件的过程，所以也降低了获得Database的时间与成本。 对于开发者来说，可以利用已有的T-SQL开发知识与熟悉的关系数据模式来使用SQL Azure进行开发和管理。SQL Azure Database可以让我们通过使用已有的开发工具，比如Visual Studio, SQL Server Management Studio来进行开发。同时SQL Azure Database还支持Ado.net, ODBC等连接方式，并且支持Entity Framework。   Criteria SQL VM SQL Azure Time to Solution     Migrate Existing Apps Fast Moderate Build New Apps Moderate Fast Cost of Solution     Hardware Administration None None Software Administration (Database & OS) Manual None Machine High Availability Automated (99.9% Uptime SLA at commercial release) N/A Database High Availability With extra VMs and manual setup via AlwaysOn (at commercial release), DBM; DR via log shipping, transactional replication Standard Feature (99.9% DB uptime SLA) Cost Medium Low Scale Model     Scale-Up A7 VM (8 cores, 56GB RAM, up to 16 TB disk space) Not Supported Scale-Out Manual via AlwaysOn read-only secondaries, scalable shared databases, peer-to-peer replication, Distributed Partitioned Views, and data-dependent routing (manual to setup, and applications must be designed for these features) SQL Database Federation (automated at data tier, with applications designed for Federation) Control & Customize     OS and VM Full Control No Control SQL Server Database Compatibility, Customization Full support for SQL Server 2012 box product features including database engine, SSIS, SSAS, SSRS Large subset of SQL Server 2012 features Hybrid     Domain Join and Windows Authentication Yes Not possible Data Synchronization via Azure Data Sync Supported Supported Manageability     Resource Governance & Security Level SQL Instance/VM Logical DB Server Tools Support Existing SQL Server tools such as SSMS, System Center, and SSDT Existing SQL Server tools such as SSMS, System Center, and SSDT Manage at Scale Capabilities Fair Good 　　SQL Azure Database有哪些新特性？ 　　SQL Azure Database会自动进行三重备份，也就是说SQL Azure Database会自动将其自身复制到同一个数据中心不同物理主机之上，产生一个主备份和2个副备份。这样就提高了SQL Azure的可靠性、可用性、企业级别的安全特性，增加了数据库的安全性。如下图所示： 　　 　　 　　Data Sync(数据同步) 　　有些特殊的情况下，可能需要让局域网内的SQL Server数据和云端的Windows Azure数据库保持数据一致，SQL Azure的Data Sync功能能方便的让您本地的SQL Server数据库服务器与云端的SQL Azure数据库进行同步。它提供单向和双向数据同步，从而让数据可以轻松地在 SQL Azure 数据库和内部部署 SQL Server 数据库之间以及在同一数据中心或不同数据中心中的多个 SQL Azure 数据库之间进行共享。   　　使用SQL Azure Database的好处是什么？ 　　(1)降低了总体拥有成本(TCO) 　　因为SQL Azure Database是云端的关系型数据库，您无需安装硬件、操作系统和数据库软件等过程，所以不需要IT人员来管理数据库，也不会产生License等费用；并且SQL Azure Database的费用是按创建个数和数据库大小来进行收费的，您在不需要的情况下也可以删除数据库，这样就不会产生任何费用。 　　(2)提高了可用性 　　因为SQL Azure Database支持三重备份，所以SQL Azure有99.9%的SLA保障。 　　(3)多租户 　　对于独立软件研发商(ISV)来说，他们可以在构建一套Web Site的情况下，使用SQL Azure。把用户的数据和配置放在相同(不同)的数据库(数据表)中进行隔离，那就可以让多个用户(租户)使用同一套系统，而且该租户只能看到自己的数据，不能看到其他租户的数据(也可以通过加密的方式，即使其他租户看到该数据也无法解析)。   　　在使用SQL Azure Database后开发模式有哪些改变？   本文转自Lei Zhang博客园博客，原文链接：http://www.cnblogs.com/threestone/p/3833397.html，如需转载请自行联系原作者

摘要：在2017杭州云栖大会阿里云HTAP技术专场上，上海秦苍信息科技有限公司DBA负责人赵怀刚为大家分享了HTPA型数据库产品在现实中的落地应用以及企业级数据库架构设计中的HTPA的应用。本文内容根据嘉宾演讲视频以及PPT整理而成。 本次分享的主题是买单侠数据库架构之路。秦苍科技是一家互联网消费金融公司，我们所有的产品基本都是托管在阿里云上的，在自己的系统中大概应用了20多种阿里云数据库产品。基于阿里云平台，秦苍科技的数据库架构与传统RDS数据运维相比存在着本质的区别。接下来着重介绍一下在产品公司业务快速发展的情况下，系统数据库架构的演变历程。 本次分享的主题主要分为以下四个部分： 一、关于秦苍科技 二、在业务的快速发展中遇到的问题 三、数据库架构演变过程和案例分析 四、基于云数据库运维的思考一、关于秦苍科技 如图所示的是秦苍科技的两个产品，最左边叫做买单侠，主要针对的是年轻蓝领客户群体，主要提供一些消费场景下的分期金融服务。右边这个产品主要目标用户群体是年轻的女性白领，主要为她们提供一些医疗美容的消费分期金融服务。目前秦苍科技公司的用户数大概为400多万，每个月新增大概20万用户，每天日活用户大概是在百万左右。秦苍科技目前做单的模式并没有完全放在线上，还是偏传统一点，会与线下的手机门店、医院、电动车销售商等这些商家合作，通过线下入口而不是直接通过APP进行操作，所以可以说秦苍科技的商业模式还是比较偏传统的。 如图所示的是秦苍科技的技术栈，主要是用的后台技术是基于Spring Cloud的微服务架构，部署则采用的是Docker技术，当然用的也是阿里云的容器服务。 秦苍科技公司成立于2014年3月，到现在大概经历了三年半的时间，目前大概遍布了全国的300个城市。系统最开始的数据库是单体架构的，所有东西都放到一起。而现在数据库有将近200个，并且对于数据库也做了拆分，目前线上的数据量已经达到了3 TB。     目前所使用的数据库架构主要采用了阿里云RDS。秦苍科技所处的是一个互金行业，所以会从一些第三方数据源那里拿数据，并与资方做交互。这些数据的变更可能比较频繁，需要依赖于第三方。对于这些数据而言，我们采取MongoDB进行存储，缓存层采用阿里云的Redis，总体而言都是采用阿里云RDS服务。   互金行业核心就是风控，秦苍科技自研了一个风控模型，这个模型叫做抱团算法，接下来大概简单介绍一下它的实现。什么是抱团呢？比如你的身边有十个朋友，如果十个朋友当中有八个朋友信用都存在问题，或者之前发生过借贷关系，但信用不是太好，就会认为你这个人有可能信用上存在问题。这个风控模型的后台采用的是neo4j图数据库集群，目前RDS的规模大概在150个MySQL、20多个MongoDB以及20个Redis。刚开始的时候采取.Net + SQL server构建的，后来把数据从SQL server迁移到了MySQL，这是因为在使用SQL server的过程当中遇到很多问题，SQL server目前不支持只读实例，在扩展性和灵活性上对业务造成了很大困扰。因为数据中心需要做数据分析，要从线上取数据，这样OLTP以及一些分析的提取都耦合不到一起。二、在业务的快速发展中遇到的问题 数据库架构演变的过程当中遇到了很多问题，所以秦苍科技的所有的技术全部选择都是在阿里云上的，包括了对于数据库的选择。使用阿里云RDS比较直接的好处就是它可以开箱即用并且可以弹性扩容。随着业务量的增加，可以轻松地升级，比如硬件上的升级，以及外围辅助的升级，还可以非常方便地实现数据迁移，后来阿里云还提供了DTS服务，可以轻松实现异构数据迁移。最初因为设计的问题，所有的数据是放在同一个实例库下，所以当出现比较高的并发时就会导致实例的CPU爆掉，进而导致数据库服务不可用。这就是所面临的问题，也是这两年时间一直在做的事情——迁移、解耦和拆分。 在这个过程中，我们遇到了异构数据迁移的问题。另外随着公司业务的发展，规模的不断变大，在整个数据库运维当中出现了效率上的问题，主要是现在有大量的SQL审核工作要做，而且有频繁的生产发布，而每次发布都要等到比较晚的时间比如业务的低谷期来发布。还有一些高频的数据查询和变更需求。主要是研发同学需要去定位Bug要获取一些数据，以上这些就是之前面临的一些问题。在开始数据规模比较小的时候使用的是比较粗暴的做法也就是人肉支撑。当发展到现在的量级，现在有3个研发中心，300多个研发同学，而DBA只有四个人，需要从DevOps角度考虑如何去支撑这么多的用户。  三、数据库架构演变过程和案例分析 如图所示是秦苍科技最早数据库的架构设计，是一个比较简单的单体架构，all in one，所有数据全部放在一个库里，可能有好几百张表。而且随着数据量的增加，OLTP都达到千万级，对于数据可用性就没法保障了。随着业务的发展，后台服务要进行微服务化架构，进行服务改造。数据库应该尽量配合后台进行微服务化的改造，这是需要思考的问题。如何进行微服务拆分呢？后来数据库团队也是在不断地摸索和思考这个问题，最后总结出拆分的大致思路，就是采取分组分层的方法，对于整个数据库进行架构的调整。 分层就是根据业务的需求特征进行分类划分主题域，这有点像数仓分析建模的概念。我们会将数据库分成不同的层次，比如可以根据需求特征分为业务、平台等层次。分组就是对主题域数据进行进一步抽象和归纳，可以抽象出来很多的逻辑组，并将逻辑组再根据具体的功能模块进一步做拆分，这可能会包含多个实例或者多个库。而针对一些业务量特别大的场景，也有使用阿里云DRDS实现水平的分表分库方案。 在分组分层时，为了节省资源和方便管理，我们做了一个小技巧，就是把不同的数据库暂时放在同一个实例上，但数据库的账号却是完全隔离的，这个账号只拥有访问某些数据库的权限。刚开始时业务量比较小，所以基于成本的考虑会放到一起。随着业务量的增加，如果出现性能问题，就可以基于阿里云DTS数据迁移服务，把数据拆分开迁入到性能比较好的实例上去。 基于上面分组分层的思想，出现了一个中间的过渡架构，这个架构也没有什么特别的，主要跟之前单体架构相比多了一个缓存层。之前的SQL Server不支持读写分离，全部迁入到MySQL之后就做了读写分离，来满足业务上读负载的瓶颈。再看一下如下图所示的现在的架构。根据业务的重要性，把整个系统分为两类，核心系统和外围系统。核心系统就是做单的系统，相当于大家到淘宝买东西，用户从商品选择到最后下单，整个流程走完是一个订单核心的系统。剩下的非做单系统，也就是大外围的系统。后台架构采用了分布式的微服务架构，服务的拆分粒度也比较细，但是这样也会遇到一些问题。 现在线上做单数据调用的服务，也会被用于分析的运营支撑系统调用，取用户订单相关信息要调多个服务，才能满足运营或分析的需求。这样，做单系统和运营支撑系统访问，数据层是耦合到一起的。于是，又找了一个折中的方法。这个折中的方法，就是选择HybirdDB，它就相当于一个大数据资源池，于是增加了Hybird DB作为数据的交换平台，主要提供核心系统和外围系统数据交换，内部叫做数据交换平台。 数据交换平台会把所有线上数据进行汇总，这样一些外围系统或者非实时请求就可以通过访问数据交换平台获取数据，这样其实对于数据交换平台提出了很大的要求：首先这个平台需要足够的大，因为现在线上数据也有3 TB，RDS实例本身没法支撑到这么大的数据量。第二，要能够很好地进行水平拆分和扩展。此外，还要完全兼容MySQL的协议。于是我们选择了HybirdDB，它解决了大的数据资源池问题。 我们同时引入了阿里运数据管理的工具——DMS，主要解决了线上实时数据的查询问题，能够做到安全的管控。另外对大数据平台计算之后的数据也做了集中的管控，可以为线上提供一些数据支撑。 微服务分布式架构演变过程中少不了数据迁移，数据迁移必然会涉及到对老模型分析、新模型设计以及新老模型之间的映射和转码等问题，所以迁移之前要做好充分准备。首先要制定迁移总体方案，包括迁移准备、实施步骤、关键点控制、应急预案等。我们借助阿里云DRDS中间件实现对核心表的水平拆分，图中的虚线部分是预案，因为属于核心的系统，这里不能有太多停机时间，需要保证数据同步。在上线过程当中，借助阿里云DTS数据迁移和订阅服务大大降低了停机时间并实现了应急预案。 如图所示的是数据库的自动化部署。SQL脚本的部署借鉴了系统发布的思路，首先要有个思维上的转变，把SQL当做是代码的一部分来运维，即：SQL as code；研发设计好数据库后，会提交一个SQL request到gitlab代码仓库，DBA收到请求后做脚本的审核，通过后会把SQL代码merge到release分支（只能DBA merge），未通过的SQL DBA会备注审核建议后驳回到研发进行调整，调整后继续走刚才审核流程。数据库发布我们采用的是flyway，在部署服务时，首先会检测本次上线发布是否有数据库的变更，如果有的话就去执行，没有就跳过。如果在执行过程当中报错或者有问题，就会通知运维进行处理，但是这种机率很小，99%以上都会成功。目前阿里云DMS实现了一些自主化审核的功能，基于定义好的规范、规则进行自动化的审核，这样就可以把上面对人依赖的点解决掉。 如图所示的是我们的监控，主要分为两个部分：对于基础资源的监控和数据的监控。基础资源的监控，是借助阿里云的监控实现的。阿里云的云监控支持短信、邮件等方式，但是不支持电话报警，所以我们又开发了自己一套电话报警机制。数据监控我们主要借助Zabbix对数据库的业务数据进行探测，如果发现异常之后会上报到电话报警平台，其也是一个第三方监控平台，它会电话通知到第一责任人。而且这个电话报警支持报警升级，如果接听人没有处理，就会打电话给负责人，使问题得到解决。上面两种监控都属于事中监控，事前监控现在比较传统主要靠DBA主动优化和巡检提前发现并解决。因为RDS会提供丰富的API，目前所有数据都可以通过API获取到，把这些数据丢到HybirdDB里进一步做分析，进行主动监控，目前我们正在尝试。 四、基于云数据库运维的思考 最后一部分是基于云数据库运维的思考。其实将所有的东西放在阿里云上使我们的工作发生了本质变化。第一个是工作前置化成为可能，使DBA向DA转变成为了可能，从之前数据库运维管理到数据的应用。向数据生命周期管理的方向靠拢是目前一个工作重心，系统有生命周期，数据一样也应该有生命周期。数据的生命周期从最初的设计到发布、维护，再到下线。而现在好多数据在设计时没有考虑它的生命周期，数据很难产生最大价值，如果把一个比较小的系统设计成高并发或者高可用的方案，会造成额外的运维和经济成本。 我们对整个DBA行业做了分类，大概分为运维DBA、应用DBA以及业务DBA。每个角色的工作重点各不一样，运维DBA更加偏重于数据库的安装和配置、HA高可用、备份容灾以及升级扩容等，这些已经被云做掉了；应用DBA是我们当前所处的阶段，主要偏重于数据库相关技术选型、容量规划、性能优化和运维自动化等，其实阿里云也在将该部分工作实现自动化和智能化，包括CloudDBA、DMS、DTS等外围增值服务,推动我们从应用DBA转向业务DBA。目前我们也在向这方面去靠拢和思考，后面的工作重心会更多地放在数据库的架构以及数据的应用上，让数据产生更多的价值，为业务提供数据支持。 下图是秦苍科技的技术公众号，上面会定期公布一些技术文章，感兴趣的同学可以关注一下。

【重点关注】Redis备份恢复方案上线，全面提升数据可靠性                                      云数据库Redis版采用双机热备的架构保证服务高可用，并且提供了持久化机制来保证数据可靠性。但是随着越来越多的业务开始使用Redis作为最终的持久化存储引擎，用户对于数据可靠性就提出了更高的需求。经过一段时间的打磨，我们正式推出了Redis备份恢复解决方案，全面的升级云数据库Redis的数据可靠性：1. 支持数据备份一键式操作 阿里云采用在备节点上执行RDB快照备份，备份期间对您的实例访问不会产生性能影响，并且提供了控制台的快捷操作可以让用户进行个性化的备份设置。2. 备份存档需求迎刃而解、数据下载轻松自如 云数据库Redis版提供了备份存档功能，且免费开放7天备份文件。也可至控制台下载文件本地保存更长时间。3. 一键数据归档，解除数据误操作的燃眉之急 内置数据库验证机制，数据归档回滚轻在控制台点击即可完成。4. 克隆实例，应对快速部署需求 客户可以根据备份文件克隆出一个新的包年包月或者按量付费实例，复杂的数据库开服部署操作采用一键式的图形化界面搞定，极大的提高了工作效率。 了解更多产品功能详情>> 关系型数据库RDS：MySQL/SQL Server/PostgreSQL/PPAS(兼容Oracle)本月新功能 1.【功能更新】RDS for MySQL高权限账号全网开启 RDS for MySQL对所有新建实例放开放创建高权限账号可选项，高权限账号支持直接在数据库里执行create\grant等指令，实现更自如的权限控制。 2.【新功能】RDS for PostgreSQL/PPAS支持基于OSS云存储的外部表读取操作。 3.【功能更新】RDS for PPAS支持控制台进行SQL审计及错误日志。 4.【售卖系统】RDS深圳多可用区（A+B）上线售卖，杭州可用区E上线售卖。   NoSQL数据库：Redis\MongoDB \Memcache本月新功能 Redis 1.云数据库Redis提供备份解决方案，支持备份设置、备份下载存档、一键回滚及克隆实例等功能 。 2.云数据库Redis上海可用区B开放售卖 。 MongoDB 1.云数据库MongoDB具备增量备份及按时间点恢复功能的能力，预计9月中旬正式在控制台可见。 PB级云数据库 PetaData本月新功能 1.云数据库Petadata已由按容量售卖改为按规格节点售卖。 2.云数据库Petadata SSD节点上线，目前可提供SATA和SSD两种存储。 3.云数据库Petadata已由邀测改为公测，接受用户申请.点此申请公测>> 云数据库 Greenplum版本月新功能 1.云数据库Greenplum版支持Greenplum通过OSS进行数据写入操作。 2.云数据库Greenplum版增加JSON数据类型，可以进行JSON格式的读写。 【热门文章】数据库技术 • 从 Java 应用部署方式看 IT 思潮——从开发和运维到开发自运维 • SQLServer · 最佳实践 · 优化案例分享• 关于MongoDB Sharding，你应该知道的• “老司机”和你聊聊云数据库系统容灾那些事• 懵懂入行，但一做就沉心钻研十年——记访谈阿里云SQL Server专家杨钊 关于我们 • ApsaraDB产品技术博客 更多精彩活动：【有“福”同享.第二季】每日一分享，虚机邮箱免费用

互联网金融行业快速发展的浪潮中，面对海量增长的数据，买单侠走出了自己的数据库架构之路。本文是买单侠DBA负责人赵怀刚在杭州云栖大会上的分享，介绍了数据库运维中遇到的问题、基于阿里云平台数据库架构的演变和案例和云数据库运维的思考。 秦苍科技是一家专注于为年轻人提供消费分期服务互联网消费金融公司，目前有“买单侠”和“星计划”系列产品，“买单侠”面向中国年轻蓝领用户，提供移动端消费分期服务。“星计划”为年轻女性用户提供医疗美容的消费金融服务。 我们目前有数百万用户，日活在百万以上，每月新增20万用户，增长速度快。消费金融区别于电商，电商重在库存管理和物流，而分期业务则更偏重于风控。因为有主动借款需求的用户信用度较差，买单侠获客的渠道偏于跟线下手机门店合作。 image 图2 买单侠数据库的发展 互联网金融行业发展速度很快，买单侠从2014年3月成立到现在三年半时间，数据库的规模和数量级也在不断的增长。目前生产中的数据库实例已经达到200+，DB数量达到了400+，在线数据量在3TB左右（不包含归档历史数据）。 买单侠的技术栈 买单侠后台技术采用的是基于 SpringCloud Netflix + Node.js的微服务架构。服务部署采用的是阿里云的容器服务，目前微服务数量达到了400+，大部分核心业务已容器化。 目前生产中使用了SQL Server、MySQL等关系型数据库，缓存采用的是Redis，另外一些数据源和第三方的数据采用的是MongoDB存储。风控技术上有自研抱团算法，风控决策模型可以协助区分好人和坏人，底层使用的是一组图数据库neo4j的集群，生产持久层90%以上是以MySQL为主。因为最早的技术栈是.net& SQL Server，还有少部分的SQL Server在使用。 发展中遇到的问题 DBA属于运维的一种，买单侠的DBA属于大的运维部门，也是把脑袋拴在别人裤腰带上干活的。要对生产稳定负责，功劳难量化，有锅就得背，但这也体现了我们的专业性。即使经常会看到上海陆家嘴的日出，但我们也有自己的目标：不仅要活着，更要活得好。我们还要有理想，万一实现了呢？ 说到这肯定会有人要问，数据库服务都托管到阿里云上，你们DBA每天还要干什么呢？其实我们也一直在思考这个问题，怎样才能顺应时代的发展，完成个人和DBA工作的升级迭代。 我们的系统最早是单体架构数据库层全部耦合在一起，数据存放在一个实例一个库下面，数据库服务的可用性没办法保证。在服务改造和拆分过程中同样存在大量的数据迁移，包括大量的异构数据迁移等。 随着公司业务快速发展和数据量增加，DBA面临大量的数据运维工作，如SQL脚本审核、频繁的生产发布以及在安全的前提下满足生产数据查询和变更等需求。 随着阿里云数据库产品的不断完善和升级迭代，怎样结合公司业务很好的集成应用将成为我们工作的重点。 **架构演变和案例 ** 最早的架构 最早的架构比较简单，是All in one的单体架构，没有缓存层，所有请求直接访问持久层，在公司初期阶段能满足当时的业务需求。 但随着业务量的增加问题不断的暴露出来，一个慢SQL导致实例CPU飙高而使所有的数据库服务不可用，数据库架构升级迫在眉睫。为了解决这个问题，接下来我们完成了数据库的拆分和代码的解耦，先是纵向拆分，迫不得已再横向拆分。 image 图3 分组分层的架构 数据库架构的主体设计思路是：分组分层、分而治之。首先从业务需求特征出发进行数据分类，划分主题域，根据主题域分层，分层的本质是职责的分离，让每层更清晰并且获得更好的伸缩性。 然后从较高的层次对业务数据进行的抽象、归纳，也就是分组（逻辑组）。因为微服务粒度太细对数据库的管理会是很大的挑战，我们跟后台微服务架构做好映射，但不是一一映射。 我们最终划分了四个层次，分别为业务线层、平台功能层、路由管理层和第三方交互层。每个层次包含多个逻辑组，例如每个产品线可以定义为一个逻辑组，每个逻辑组会根据功能模块垂直拆分为多个物理实例。 例如有信贷核心平台组，下面会包含账务、账户、借据和交易等功能模块，每个模块分散到不同的物理实例，相互间不会产生影响。个别业务数据量大的实例根据业务键的哈希算法进行水平拆分。业务数据通过垂直和水平拆分后全部打散部署。 中间的架构 在分组分层垂直拆分的基础上，我们增加了Redis作为缓存层，储存一些数据量小但是访问频率很高的数据，比如字典服务、产品配置、费率等相关数据。 image 图4 中间的架构 跟之前的单体架构相比，除了增加缓存层和架构上垂直拆分打散部署外，部分业务还增加从库实现读写分离和负载均衡。 **现在的架构 ** 随着业务发展和微服务化的推进，发现服务层做了很好的管控，但数据层并没有区分，运营和生产做单等还是访问同一份数据。于是我们根据业务重要性把数据库分为了两类，一个是小核心的做单系统，一个是非做单系统的大外围，也就是瘦核心的思想。 跟上面中间架构的区别主要有三点： image 图5 现在的架构 增加了一个数据集成区或者叫数据交换平台，是一个数据交换的枢纽，实现核心业务系统与外围系统间的数据交换。上面这个OLTP定义为小核心层提供联机实时、小数据量的数据服务，保证核心业务服务请求做到实时快速的响应。数据交换平台层提供批量、大数据量、准实时的数据服务，为运营和准实时数据分析提供数据支持。 举个例子，如放款服务要依赖于审核服务，要等到审核返回结果后才能继续处理，这种实时性要求高而且报文不大的可以走OLTP小核心层。如果对实时性要求不高，可以准实时传送、数据量又比较大的就走数据交换平台，如每天的对账业务、运营平台查询和大数据平台的对接等业务场景。数据交换平台是一个大的数据资源池，必须满足两点要求：一个是要能够足够的大，而且能够很好的水平扩展，第二要兼容MySQL协议。 HybridDB 是阿里云自研的数据库产品，同时支持海量数据在线事务（OLTP）和在线分析（OLAP）的混合型分布式关系型数据库，高度兼容SQL，支持海量数据，类似于AWS的Redshift，结合阿里云的DTS服务可以完全满足我们的架构需求。 对大数据回流数据做了规范化和集中管控，之前是直接回推到生产各个OLTP实例，做法也比较暴力，直接truncate后全量插入，问题是比较分散而且容易对已有实例产生影响。我们对所有回流数据进行梳理，把所有回流数据当做是其中一个数据集市，不同业务服务所需数据对应到不同的库和账号存放在同一个数据集市，采取增量推送模式，同时要求线上业务服务做好容错机制，如果推送失败后做好处理避免产生强依赖。 3.引入了DMS数据管理工具，用户可以通过DMS直接访问数据交换平台，在安全、稳定的前提下可以满足研发对生产数据的自助访问，而且支持数据变更和SQL审核，为数据库运维提供了一站式的DevOps解决方案，可以释放DBA做更有价值的业务模型和架构设计。 如何进行数据迁移？ image 图6 分表分库案例 微服务分布式架构演变过程中少不了数据迁移，数据迁移必然会涉及到对老模型分析、新模型设计以及新老模型之间的映射和转码等问题，所以迁移之前要做好充分准备。首先要制定迁移总体方案，包括迁移准备、实施步骤、关键点控制、应急预案等。 我们核心账务系统的迭代过程分三步： 1.代码做服务化数据库层不做变动，从单体架构中拆分到独立的数据库实例。 2.将数据库从SQLServer迁移到MySQL并实现读写分离。 3.使用DRDS实现对大表的切分，解决了单表数据量大的问题。 右边虚线框内为第三步Sharding的预案，使用阿里云DTS的数据迁移先把RDS数据实时同步到DRDS，借助DTS订阅和补偿机制实现对DRDS Sharding 后数据的汇总实现上线后的应急预案。而且这两个操作都可以在线提前执行，服务上线时只是做个配置变更和重启秒级完成，大大缩减了停机时间。 如何部署？ image 图7 数据运维Pipeline SQL脚本的部署借鉴了系统发布的思路，首先要有个思维上的转变，把SQL当做是代码的一部分来运维（这里主要是指发布的DDL&DML SQL），即SQL ascode，从最初的数据库设计到审核到发布和优化看做是SQL 运维的pipeline。研发设计好数据库后，会提交一个SQLrequest到gitlab代码仓库，DBA收到请求后做脚本的审核，通过后会把SQL代码merge到release分支（只能DBA merge）。未通过的SQL DBA会备注审核建议后驳回到研发进行调整，调整后继续走刚才审核流程。 上线发布时我们采用了flyway，实现自动部署和以及跟代码发布的集成，上线相关DDL/DML的SQL会被当做代码推送到代码仓库，代码部署完成服务启动时会检查本次变更是否存在SQL脚本，有的话就执行没有就跳过。flyway具备版本控制、rollback机制，因为数据库是有状态的服务，我们没使用这些功能。 如果执行过程中报错或失败，将不再启动服务人工介入排查。数据库发布和代码部署做了很好的集成，这样提高了数据库运维和发布效率，跟上互联网快速发展的节奏。 上线后的优化中，主要是慢SQL的管理分为两类，一类是索引类由DBA后台空窗期维护，另一类是SQL需改写通过Bug管理流程进行跟踪，这样整个数据库的运维从设计-审核-发布-优化完成了闭环。 上面流程中SQL审核还是人工执行，肯定会存在瓶颈。最初我们想做一个类似于代码检测或扫描的工具：SQL Scan，可以基于预先定义好的规则进行SQL自动发现并审核，审核有问题的SQL再抛出来给DBA确认，这样可以节省80%以上的审核时间。后来我们发现阿里云的DMS已具备类似功能，目前正在跟DMS做研发流程上的集成，也算是基于云端DevOps的快速实现。 数据库的监控 数据库的监控分为两个部分：基础资源监控和数据监控。 基础资源监控主要借助阿里云监控实现，包括对CPU、磁盘、IOPS、QPS/TPS等常规指标监控，报警方式支持短信、邮件和集成钉钉通知。 数据监控我们主要借助Zabbix对数据库的业务数据进行探测，发现异常后上报到灵犀报警。灵犀报警是一个第三方监控平台，支持电话报警，紧急事件可以打电话给第一责任人处理，并且支持报警升级，第一责任人未响应的情况下会继续上报到backup人员，确保报警得到尽快解决。 另外阿里云的监控存在两个问题，一个是跨度周期长的监控数据会被平均化，很难定位到当时的负载和问题，二是有固定的保留期限，很难查到半年前的监控历史数据。而且上面两种监控都属于事中监控，事前监控现在比较传统主要靠DBA主动优化和巡检提前发现并解决。阿里云的RDS有对所有监控提供API，能够通过API获取到监控数据明细，导入到ELK等做进一步的处理和分析，算是大数据应用在数据库监控的场景，目前在尝试。 AI会取代DBA么？ 云数据库运维的思考 最近Oracle的OOW大会有提出一个新的名词：自治数据库，把18c定位为可以自动驾驶的自治数据库，结合机器学习实现了自我管理、自我调节、自我安全和自我修复等功能。目前阿里云已有16种数据库产品，最近阿里云也有发布CloudDBA、PolarDB，而且我们所有的数据库都托管在阿里云上。云最大的好处是开箱即用和弹性伸缩，基础运维的工作基本已被取代，再加上CloudDBA、DTS、DMS等DevOps把云端整个数据库运维打通，形成了闭环。 在云端不需要开发运维就可以快速实现运维的自动化和智能化，感觉我们的末日就要来了。但仔细想想AI要完全取代DBA的工作，其实还需要漫长的过程。就好像自动驾驶技术落地一样。 DBA的工作进化 基于云平台，我们的工作也发生了很大的变化，云使工作前置化成为可能，使DBA转向DA成为可能，从底层运维转向结合业务场景的数据库设计，从数据库管理转向数据管理和数据应用。我们目前要求DBA也要参加架构评审，从项目开始便了解业务，多与产品和研发沟通，搞清楚业务的商业价值和后台技术实现，站在DBA的视角给出与数据设计相关的建议，这也是DBA工作前置化的表现，变被动为主动。 DBA主动了解数据库以外的知识，了解业务、平台、云等，这样才能在众多选择中做好合理规划而不至于迷失，完成从DBA到DA的转型。 数据库生命周期管理 站在产品的角度看每个系统都是有生命周期的，数据也是一样，未来会发展成什么样子？将一个在其生命周期内不会产生高并发和大数据量的数据库，设计成高并发和水平扩展的架构，这种行为就是在耍流氓。 image 图8 数据生命周期管理 要充分考虑到数据架构是否对当前业务支持。过度或不合理的设计会带来额外的运维和经济成本。所以我们认为数据生命周期管理将会成为DBA未来工作的重点，DBA将围绕数据展开工作。这就要求我们站在系统或产品运营的角度来看待数据运维，这将是一件非常有意义的事情。对于数据的设计我们看做是产品的迭代一样，采用IPO（input-process-output）的方式，数据从输入-处理-输出完成整个生命周期迭代。 思考和总结 梳理下DBA的工作可以分为：运维DBA、应用DBA和业务DBA。每一个角色的工作重点各不一样，运维DBA更加偏重于数据库的安装和配置、HA高可用、备份容灾以及升级扩容等。 image 图9 思考和总结 应用DBA是我们当前所处的阶段，主要偏重于数据库相关技术选型、容量规划、性能优化和运维自动化等。其实阿里云也在将该部分工作实现自动化和智能化，包括CloudDBA、DMS、DTS等外围增值服务。随着云产品的不断完善和数据库技术的快速发展，会向业务DBA发展，注重于结合业务场景的数据库设计，数据管理和数据应用，用数据来驱动业务为企业创造更大价值。** 作者介绍 image 赵怀刚 2016年1月加入秦苍科技，现任上海秦苍科技（买单侠）DBA负责人，在此之前曾在广达集团，炫踪游戏，爱代驾等互联网技术公司任职。 毕业于郑州大学计算机专业，具有10年的开发、数据架构和运维经验，对MySQL、SQL Server、MongoDB有着丰富的运维经验，擅长解决各类线上突发问题及性能优化，现在专注于数据架构、数据管理和自动化数据运维方向。

互联网金融行业快速发展的浪潮中，面对海量增长的数据，买单侠走出了自己的数据库架构之路。 本文是买单侠DBA负责人赵怀刚在杭州云栖大会上的分享，介绍了数据库运维中遇到的问题、基于阿里云平台数据库架构的演变和案例和云数据库运维的思考。图1 赵怀刚在分享 秦苍科技是一家专注于为年轻人提供消费分期服务互联网消费金融公司，目前有“买单侠”和“星计划”系列产品，“买单侠”面向中国年轻蓝领用户，提供移动端消费分期服务。“星计划”为年轻女性用户提供医疗美容的消费金融服务。 我们目前有数百万用户，日活在百万以上，每月新增20万用户，增长速度快。 消费金融区别于电商，电商重在库存管理和物流，而分期业务则更偏重于风控。因为有主动借款需求的用户信用度较差，买单侠获客的渠道偏于跟线下手机门店合作。图2 买单侠数据库的发展 互联网金融行业发展速度很快，买单侠从2014年3月成立到现在三年半时间，数据库的规模和数量级也在不断的增长。 目前生产中的数据库实例已经达到200+，DB数量达到了400+，在线数据量在3TB左右（不包含归档历史数据）。 买单侠的技术栈 买单侠后台技术采用的是基于 SpringCloud Netflix + Node.js的微服务架构。 服务部署采用的是阿里云的容器服务，目前微服务数量达到了400+，大部分核心业务已容器化。 目前生产中使用了SQL Server、MySQL等关系型数据库，缓存采用的是Redis，另外一些数据源和第三方的数据采用的是MongoDB存储。 风控技术上有自研抱团算法，风控决策模型可以协助区分好人和坏人，底层使用的是一组图数据库neo4j的集群，生产持久层90%以上是以MySQL为主。 因为最早的技术栈是.net& SQL Server，还有少部分的SQL Server在使用。 发展中遇到的问题 DBA属于运维的一种，买单侠的DBA属于大的运维部门，也是把脑袋拴在别人裤腰带上干活的。 要对生产稳定负责，功劳难量化，有锅就得背，但这也体现了我们的专业性。 即使经常会看到上海陆家嘴的日出，但我们也有自己的目标： 不仅要活着，更要活得好。我们还要有理想，万一实现了呢？ 说到这肯定会有人要问，数据库服务都托管到阿里云上，你们DBA每天还要干什么呢？ 其实我们也一直在思考这个问题，怎样才能顺应时代的发展，完成个人和DBA工作的升级迭代。 我们的系统最早是单体架构数据库层全部耦合在一起，数据存放在一个实例一个库下面，数据库服务的可用性没办法保证。 在服务改造和拆分过程中同样存在大量的数据迁移，包括大量的异构数据迁移等。 随着公司业务快速发展和数据量增加，DBA面临大量的数据运维工作，如SQL脚本审核、频繁的生产发布以及在安全的前提下满足生产数据查询和变更等需求。 随着阿里云数据库产品的不断完善和升级迭代，怎样结合公司业务很好的集成应用将成为我们工作的重点。 架构演变和案例 最早的架构最早的架构比较简单，是All in one的单体架构，没有缓存层，所有请求直接访问持久层，在公司初期阶段能满足当时的业务需求。 但随着业务量的增加问题不断的暴露出来，一个慢SQL导致实例CPU飙高而使所有的数据库服务不可用，数据库架构升级迫在眉睫。 为了解决这个问题，接下来我们完成了数据库的拆分和代码的解耦，先是纵向拆分，迫不得已再横向拆分。图3 分组分层的架构 数据库架构的主体设计思路是：分组分层、分而治之。 首先从业务需求特征出发进行数据分类，划分主题域，根据主题域分层，分层的本质是职责的分离，让每层更清晰并且获得更好的伸缩性。 然后从较高的层次对业务数据进行的抽象、归纳，也就是分组（逻辑组）。 因为微服务粒度太细对数据库的管理会是很大的挑战，我们跟后台微服务架构做好映射，但不是一一映射。 我们最终划分了四个层次，分别为业务线层、平台功能层、路由管理层和第三方交互层。 每个层次包含多个逻辑组，例如每个产品线可以定义为一个逻辑组，每个逻辑组会根据功能模块垂直拆分为多个物理实例。 例如有信贷核心平台组，下面会包含账务、账户、借据和交易等功能模块，每个模块分散到不同的物理实例，相互间不会产生影响。 个别业务数据量大的实例根据业务键的哈希算法进行水平拆分。业务数据通过垂直和水平拆分后全部打散部署。 中间的架构在分组分层垂直拆分的基础上，我们增加了Redis作为缓存层，储存一些数据量小但是访问频率很高的数据，比如字典服务、产品配置、费率等相关数据。图4 中间的架构跟之前的单体架构相比，除了增加缓存层和架构上垂直拆分打散部署外，部分业务还增加从库实现读写分离和负载均衡。 现在的架构 随着业务发展和微服务化的推进，发现服务层做了很好的管控，但数据层并没有区分，运营和生产做单等还是访问同一份数据。 于是我们根据业务重要性把数据库分为了两类，一个是小核心的做单系统，一个是非做单系统的大外围，也就是瘦核心的思想。 跟上面中间架构的区别主要有三点：图5 现在的架构 1.增加了一个数据集成区或者叫数据交换平台，是一个数据交换的枢纽，实现核心业务系统与外围系统间的数据交换。 上面这个OLTP定义为小核心层提供联机实时、小数据量的数据服务，保证核心业务服务请求做到实时快速的响应。 数据交换平台层提供批量、大数据量、准实时的数据服务，为运营和准实时数据分析提供数据支持。 举个例子，如放款服务要依赖于审核服务，要等到审核返回结果后才能继续处理，这种实时性要求高而且报文不大的可以走OLTP小核心层。 如果对实时性要求不高，可以准实时传送、数据量又比较大的就走数据交换平台，如每天的对账业务、运营平台查询和大数据平台的对接等业务场景。 数据交换平台是一个大的数据资源池，必须满足两点要求：一个是要能够足够的大，而且能够很好的水平扩展，第二要兼容MySQL协议。 HybridDB 是阿里云自研的数据库产品，同时支持海量数据在线事务（OLTP）和在线分析（OLAP）的混合型分布式关系型数据库，高度兼容SQL，支持海量数据，类似于AWS的Redshift，结合阿里云的DTS服务可以完全满足我们的架构需求。 2.对大数据回流数据做了规范化和集中管控，之前是直接回推到生产各个OLTP实例，做法也比较暴力，直接truncate后全量插入，问题是比较分散而且容易对已有实例产生影响。 我们对所有回流数据进行梳理，把所有回流数据当做是其中一个数据集市，不同业务服务所需数据对应到不同的库和账号存放在同一个数据集市，采取增量推送模式，同时要求线上业务服务做好容错机制，如果推送失败后做好处理避免产生强依赖。 3.引入了DMS数据管理工具，用户可以通过DMS直接访问数据交换平台，在安全、稳定的前提下可以满足研发对生产数据的自助访问，而且支持数据变更和SQL审核，为数据库运维提供了一站式的DevOps解决方案，可以释放DBA做更有价值的业务模型和架构设计。 如何进行数据迁移？ 图6 分表分库案例 微服务分布式架构演变过程中少不了数据迁移，数据迁移必然会涉及到对老模型分析、新模型设计以及新老模型之间的映射和转码等问题，所以迁移之前要做好充分准备。 首先要制定迁移总体方案，包括迁移准备、实施步骤、关键点控制、应急预案等。 我们核心账务系统的迭代过程分三步： 1.代码做服务化数据库层不做变动，从单体架构中拆分到独立的数据库实例。 2.将数据库从SQLServer迁移到MySQL并实现读写分离。 3.使用DRDS实现对大表的切分，解决了单表数据量大的问题。 右边虚线框内为第三步Sharding的预案，使用阿里云DTS的数据迁移先把RDS数据实时同步到DRDS，借助DTS订阅和补偿机制实现对DRDS Sharding 后数据的汇总实现上线后的应急预案。 而且这两个操作都可以在线提前执行，服务上线时只是做个配置变更和重启秒级完成，大大缩减了停机时间。 如何部署？ 图7 数据运维Pipeline SQL脚本的部署借鉴了系统发布的思路，首先要有个思维上的转变，把SQL当做是代码的一部分来运维（这里主要是指发布的DDL&DML SQL），即SQL ascode，从最初的数据库设计到审核到发布和优化看做是SQL 运维的pipeline。 研发设计好数据库后，会提交一个SQLrequest到gitlab代码仓库，DBA收到请求后做脚本的审核，通过后会把SQL代码merge到release分支（只能DBA merge）。 未通过的SQL DBA会备注审核建议后驳回到研发进行调整，调整后继续走刚才审核流程。 上线发布时我们采用了flyway，实现自动部署和以及跟代码发布的集成，上线相关DDL/DML的SQL会被当做代码推送到代码仓库，代码部署完成服务启动时会检查本次变更是否存在SQL脚本，有的话就执行没有就跳过。 flyway具备版本控制、rollback机制，因为数据库是有状态的服务，我们没使用这些功能。 如果执行过程中报错或失败，将不再启动服务人工介入排查。数据库发布和代码部署做了很好的集成，这样提高了数据库运维和发布效率，跟上互联网快速发展的节奏。 上线后的优化中，主要是慢SQL的管理分为两类，一类是索引类由DBA后台空窗期维护，另一类是SQL需改写通过Bug管理流程进行跟踪，这样整个数据库的运维从设计-审核-发布-优化完成了闭环。 上面流程中SQL审核还是人工执行，肯定会存在瓶颈。 最初我们想做一个类似于代码检测或扫描的工具：SQL Scan，可以基于预先定义好的规则进行SQL自动发现并审核，审核有问题的SQL再抛出来给DBA确认，这样可以节省80%以上的审核时间。 后来我们发现阿里云的DMS已具备类似功能，目前正在跟DMS做研发流程上的集成，也算是基于云端DevOps的快速实现。 数据库的监控 数据库的监控分为两个部分：基础资源监控和数据监控。 基础资源监控主要借助阿里云监控实现，包括对CPU、磁盘、IOPS、QPS/TPS等常规指标监控，报警方式支持短信、邮件和集成钉钉通知。 数据监控我们主要借助Zabbix对数据库的业务数据进行探测，发现异常后上报到灵犀报警。 灵犀报警是一个第三方监控平台，支持电话报警，紧急事件可以打电话给第一责任人处理，并且支持报警升级，第一责任人未响应的情况下会继续上报到backup人员，确保报警得到尽快解决。 另外阿里云的监控存在两个问题，一个是跨度周期长的监控数据会被平均化，很难定位到当时的负载和问题，二是有固定的保留期限，很难查到半年前的监控历史数据。 而且上面两种监控都属于事中监控，事前监控现在比较传统主要靠DBA主动优化和巡检提前发现并解决。 阿里云的RDS有对所有监控提供API，能够通过API获取到监控数据明细，导入到ELK等做进一步的处理和分析，算是大数据应用在数据库监控的场景，目前在尝试。 AI会取代DBA么？云数据库运维的思考 最近Oracle的OOW大会有提出一个新的名词：自治数据库，把18c定位为可以自动驾驶的自治数据库，结合机器学习实现了自我管理、自我调节、自我安全和自我修复等功能。 目前阿里云已有16种数据库产品，最近阿里云也有发布CloudDBA、PolarDB，而且我们所有的数据库都托管在阿里云上。 云最大的好处是开箱即用和弹性伸缩，基础运维的工作基本已被取代，再加上CloudDBA、DTS、DMS等DevOps把云端整个数据库运维打通，形成了闭环。 在云端不需要开发运维就可以快速实现运维的自动化和智能化，感觉我们的末日就要来了。 但仔细想想AI要完全取代DBA的工作，其实还需要漫长的过程。就好像自动驾驶技术落地一样。 DBA的工作进化 基于云平台，我们的工作也发生了很大的变化，云使工作前置化成为可能，使DBA转向DA成为可能，从底层运维转向结合业务场景的数据库设计，从数据库管理转向数据管理和数据应用。 我们目前要求DBA也要参加架构评审，从项目开始便了解业务，多与产品和研发沟通，搞清楚业务的商业价值和后台技术实现，站在DBA的视角给出与数据设计相关的建议，这也是DBA工作前置化的表现，变被动为主动。 DBA主动了解数据库以外的知识，了解业务、平台、云等，这样才能在众多选择中做好合理规划而不至于迷失，完成从DBA到DA的转型。 数据库生命周期管理 站在产品的角度看每个系统都是有生命周期的，数据也是一样，未来会发展成什么样子？ 将一个在其生命周期内不会产生高并发和大数据量的数据库，设计成高并发和水平扩展的架构，这种行为就是在耍流氓。图8 数据生命周期管理 要充分考虑到数据架构是否对当前业务支持。过度或不合理的设计会带来额外的运维和经济成本。 所以我们认为数据生命周期管理将会成为DBA未来工作的重点，DBA将围绕数据展开工作。 这就要求我们站在系统或产品运营的角度来看待数据运维，这将是一件非常有意义的事情。对于数据的设计我们看做是产品的迭代一样，采用IPO（input-process-output）的方式，数据从输入-处理-输出完成整个生命周期迭代。 思考和总结 梳理下DBA的工作可以分为：运维DBA、应用DBA和业务DBA。 每一个角色的工作重点各不一样，运维DBA更加偏重于数据库的安装和配置、HA高可用、备份容灾以及升级扩容等。图9 思考和总结 应用DBA是我们当前所处的阶段，主要偏重于数据库相关技术选型、容量规划、性能优化和运维自动化等。 其实阿里云也在将该部分工作实现自动化和智能化，包括CloudDBA、DMS、DTS等外围增值服务。 随着云产品的不断完善和数据库技术的快速发展，会向业务DBA发展，注重于结合业务场景的数据库设计，数据管理和数据应用，用数据来驱动业务为企业创造更大价值。

对于很多国外IT企业来说，中国市场已经成为当下最为紧俏的海外市场，这个市场不仅拥有巨大的互联网和移动互联网用户群体，同时还拥有全球十分之一的开发者群体。而后者也正是开源数据库MongoDB所最为看重的。 MongoDB总裁兼首席执行官Dev Ittycheria 八月初，MongoDB举办了中国年度用户大会，这也是MongoDB在进入中国以来首次召开的用户大会。面对座无虚席的会场，MongoDB总裁兼首席执行官Dev Ittycheria对中国市场表现出了极高的兴趣，他表示：“目前，MongoDB 在全球的下载量超过2000万次，而中国是下载量最大的国家，这也是我们非常看重中国市场的原因所在。” 2016年8月份DB-Engines发布的数据库系统排名榜单显示，在全球超过250种数据库的综合排名中，Oracle、MySQL、SQL Server因其庞大的市场体量稳居第一阵营，MongoDB作为数据库新星也表现不错，打败了众多关系型数据库和其他现代数据库，位居排行榜第四，而且这个排位也已经持续了很长时间，也说明MongoDB在稳步发展。 中国市场为MongoDB贡献了非常多的力量，除了巨大的下载量，在MongoDB进入中国之前，上千家中国机构使用MongoDB实现业务变革和现代化，其中包括十分活跃的消费者科技企业，如滴滴出行、百度，以及一些传统企业，如中国东方航空和富士康等。 中国东航航空公司信息部领域架构师童帅华表示：“东航和许多传统企业一样，在选择MongoDB之前一直用关系型数据库，但是随着业务需求的变化，一些诸如多地图区域搜索、主题搜索、灵感语义搜索等新的业务需求诞生出来，另外一方面随着新的业务发展，预计未来能达到每天8亿次到10亿次查询次数，这种情况下，传统数据库已经无法满足需要了。” 目前，东航拥有超过510架的机队，通达世界177个国家和地区，年服务旅客 8000余万人，机队规模、旅客运输量等多项运营指标跨入全球航空公司十强。作为国家首批民航独家两化融合标杆试点企业，东航的IT自动化覆盖率达到95%，移动端日点击量达到200万，旅客自助服务率达到60%。 在发展中，东航的发展战略是转型成为综合服务集成商，在这一战略转型过程中，东航一方面要持续巩固主营业务的核心竞争力，另一方面要从附加服务产品和非航产品销售入手拓展新业务。 不过，由于技术限制等原因，老一代旅客服务系统PSS无法支持东航的转型策略：一方面用户访问量难以预测和并发数剧增，老系统无法支持以旅客为中心的销售模式和灵活的渠道控制；一方面，旅客服务更加个性化，系统间集成度更高，例如机上服务、机票查询、自助值机以及酒店、租车等非航空业务等，这些也都给老系统造成了不小的压力；除此之外，老系统对于增值服务的支持也不灵光，非航附加产品丰富, 原有PSS数据结构设计跟不上发展。 基于以上原因和考量，东航决定新一代的PSS系统将采用开放式、开源化的技术路线，而MongoDB在其中起到了非常重要的作用。通过部署MongoDB，为旅客个性化搜索提供支持，满足消费者对低价日历、地图规划、灵感语义搜索等的需求。目前，数据库总条数约720亿，每天插入更新次数2600万次，每当的查询量达到4500万次，其中80%的查询响应时间低于50ms，99%以上的查询低于100ms，而CPU利用率<30%，大大降低了机票查询响应时间，改善用户使用体验，提高了直销率。 东航所面临的问题，其他传统企业也或多或少遇到过。Dev Ittycheria表示：“如何利用软件推进业务发展，这一点几乎决定了当今所有企业的走向，而企业在软件项目的成功取决于如何利用软件开发人员的创造力和生产力。数以百万计具有远见卓识的机构正通过在更加灵活强大、更具扩展性的基础设施上构建更加先进复杂的应用，以释放软件和数据的巨大能量，变革并加速其业务发展。” 事实上，随着移动互联网和互联网的发展，企业在推进自身数字化转型的过程中，应用要支持应用要支持更多样的数据，除了以前的结构化数据，应用还要支持图片、音视频等非结构化数据，以及社交应用数据等半结构化数据；业务要求更快的发布，甚至一些数字化程度高的行业企业需要功能周周升级，业务月月发布；系统要处理PB甚至TB级别的数据，支持每秒百万级的访问量；数据治理向Data as Service发展，企业架构向微服务架构演进。 要满足以上这些需求，曾经独霸天下的关系型数据库实在有些力不从心，而这就成了MongoDB等现代数据库的市场机遇。 MongoDB大中华区地区副总裁Steve Su在接受记者采访时说：“虽然MongoDB进入中国市场的时间尚短，但是由于开源数据库的特点使然，MongoDB已经拥有了大量的企业级用户，这些用户在使用过程肯定或多或少都遇到了一些问题，需要MongoDB为他们提供企业级的服务支持。” 据介绍，MongoDB在2015财年发现，用户30%的使用量来自于企业原有业务的迁移，70%是新开发应用，而在此前数据库的使用量中90%都是新应用。这些数据显示，传统企业对现代数据库的接受程度越来越高。 对于中国市场，MongoDB的预期是到明年，用户数增加两到三倍。九个月前，MongoDB任命Steve Su为大中华区负责人，此后MongoDB中国团队迅速组建起来，并在上海、北京、深圳、香港设立办事处，吸纳营销、销售、技术等方面的人才。MongoDB还计划与合作伙伴一道设立运营中心。 另外一方面，为更好地支持中国本地用户，MongoDB正在推出本地语言资源，并开发出新的产品功能，包括具备中文搜索的原生支持以及先进的管理工具和企业功能等。 此外，在培养开发者方面，MongoDB也是倍下苦心。MongoDB战略副总裁Kelly Stirman介绍道，除了不断收集开发者需求，并针对这些需求对产品进行改进，调高产品的友好度外，MongoDB还设立了开发者大学，通过在线学习的方式帮助其更好使用开源数据库。Kelly Stirman表示：“大概有40万人使用了我们MongoDB的课程。” Dev Ittycheria告诉记者：“我们很高兴与中国许多最具创新性的机构进行合作，这种挑战和机遇的规模在世界任何地方都是史无前例的。” 原文发布时间为：2016年8月12日  本文作者：作者：赵东 本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。

使用PolarDB和ECS搭建门户网站 一、创建PolarDB数据库账号 1. 单击页面左侧 云产品资源 > 一键复制登录url 。2. 打开浏览器隐身窗口（无痕模式），粘贴已复制的url地址前往 RAM用户登录 界面，登录 阿里云管理控制台 。 a. 依次单击更多>打开新的无痕窗口。 b. 在地址栏粘贴登录url，访问 RAM用户 登录页面 c. 在登录用户名称处，输入 子用户名称 ，单击 下一步 。 d. 输入密码，单击 登录 进入 阿里云管理控制台 。 3. 在 阿里云控制台首页 左侧导航栏，依次单击 产品与服务 > 云数据库PolarDB ，进入 云数据库PolarDB管理控制台 。 4. 单击左侧 集群列表 ，然后选择云产品资源提供的地域。例如：华东2（上海）。 5. 创建数据库账号。 a. 在 集群列表 页面，单击 集群ID ，进入 集群详情界面 。 b. 单击左侧导航栏 配置与管理 > 账号管理 。 c. 单击左上方 创建账号 。 d. 参考说明配置账号信息，然后单击 确定 。 数据库账号：输入数据库账号名称，例如：test_user 。账号类型：此处选择普通账号。密码：设置账号密码，例如：Password1213。确认密码：再次输入密码。6. 创建数据库。 a. 在实例详情页，单击左侧导航栏的 数据库管理 ，然后单击 创建数据库 。 b. 参考说明配置数据库信息，然后单击 创建 。 数据库（DB）名称：输入数据库名称，例如：pbootcms 。支持字符集：默认设为utf8mb4。授权账号：选择上一步创建的数据库账号test_user。账号类型：默认设置为读写。备注说明：非必填。用于备注该数据库的相关信息，便于后续数据库管理，最多支持256个字符。 7. 设置数据库白名单。 连接数据库需要设置数据库白名单，点击 [集群白名单]，然后点击 [设置] 设置数据库集群白名单。在白名单界面将默认的白名单地址127.0.0.1更改为 0.0.0.0/0，然后点击 [确定] 使白名单地址生效。 二、连接ECS服务器 还是和之前一样的老套路，通过ssh命令连接就ok 三、安装LAMP环境 LAMP是指运行在Linux下的Apache、MySQL和PHP的环境。参考以下操作在云服务器上安装开发环境。 1. 在ECS服务器上，执行以下命令安装Apache服务及其扩展包。 yum -y install httpd httpd-manual mod_ssl mod_perl mod_auth_mysql 返回类似如下图结果则表示安装成功。 2. PbootCMS是使用PHP语言开发的CMS系统。参考以下操作安装PHP环境。 执行以下命令，安装PHP。 yum -y install php php-mysql gd php-gd gd-devel php-xml php-common php-mbstring php-ldap php-pear php-xmlrpc php-imap 3. 执行以下命令下载并安装MySQL。 wget http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm yum -y install mysql57-community-release-el7-10.noarch.rpm yum -y install mysql-community-server 4. 执行以下命令启动MySQL数据库。 systemctl start mysqld 五、搭建门户网站 在完成环境部署后，参考以下操作搭建门户网站。 1. 在ECS服务器上，执行以下命令，安装Git。 yum -y install git 2. 在ECS服务器上，执行以下命令下载PbootCMS源码文件。 cd ~ && git clone https://gitee.com/hnaoyun/PbootCMS.git 3. 执行以下命令将安装包拷贝到Apache的wwwroot目录下。 cp -r PbootCMS/* /var/www/html/ 4. 执行以下命令修改站点根目录文件权限。 chmod -R a+w /var/www/html 4. 向数据库中导入CMS的初始数据。 执行以下命令初始化数据库pbootcms的表结构和数据。说明: 在执行命令前，请修改一下三个参数。数据库连接地址参见集群详情页面下方链接地址板块。test_user为步骤二中创建的数据库账号。Password1213步骤二中创建的数据库密码。sql_file="/var/www/html/static/backup/sql/"$(ls /var/www/html/static/backup/sql/) &&mysql -h数据库连接地址 -utest_user -pPassword1213 -Dpbootcms < $sql_file 5. 执行以下命令，修改CMS系统数据库配置。 cat > /var/www/html/config/database.php << EOF <?php return array( 'database' => array( 'type' => 'mysqli', // 数据库连接驱动类型: mysqli,sqlite,pdo_mysql,pdo_sqlite 'host' => '数据库连接地址', // PolarDB数据库链接地址 'user' => 'test_user', // PolarDB数据库的用户名 'passwd' => 'Password1213', // PolarDB数据库的密码 'port' => '3306', // 数据库端口 'dbname' => 'pbootcms' //数据库名称 ) ); EOF 6. 返回ECS控制台，在ECS实例列表页面，单击已创建的ECS实例ID链接进入ECS详情页。 7. 在左侧导航栏，单击 本实例安全组 ，然后单击安全组的ID链接查看安全组配置。 确保安全组开放了80端口访问，否则无法访问已搭建的门户网站。安全组是一种虚拟防火墙，具备状态检测和数据包过滤能力，用于在云端划分安全域。通过配置安全组规则，您可以控制安全组内一台或多台ECS实例的入流量和出流量。 8. 访问程序。 执行以下命令重启 Apache服务。 systemctl restart httpd在浏览器地址栏输入云服务器的公网IP地址，进入门户网站首页。 系统后台默认访问路径为http://公网IP地址>/admin.php。默认账号为admin，密码为123456。 至此您已完成门户网站的搭建，您可以根据公司的需求自定义门户网站的内容。

上云前序    ​    ​我们公司因为业务需求，需要来服务器托管微信公众号平台。之前我们先是自建服务器，然后就是使用IDC机房托管服务器，后来因为种种原因，最后转到了阿里云上云。很多同学会有疑问，为什么已经有了自建服务器，还需要去IDC机房托管，最后又去上云呢？    ​   ​因为在自建服务器的时候，这个服务器是由我们公司一群参差不齐不齐的"网络工程师"一起弄的。这群吃货，往往是对编程语言有所了解，但对硬件了解的不甚多。所以在遇到单点故障的时候，大家都一脸懵逼。还有，遇到宕机的时候，我们还需要为每个硬件准备冗余，部署与维护成本成本就上去了。     ​  同时，增减硬件也是挺麻烦的，带宽也是。有时候需要临时搞活动，硬件需要购置时间。带宽也不能提升，因为我这边的ISP服务商签约是一年的。电费也是超贵的，一台低配置的预发型版本测试服务器一年下来电费也得3000元。所以后来我们就换成了IDC机房。     ​   而然，问题还是没有得到解决。即使我们租用的是双线路由器，但是南北互通问题还是解决不了。究竟什么是南北互通问题？基于我们的理解简体描述一下，不对之处欢迎指出。南北互通问题实际就是路由问题。假设我们的服务器放在上海电信的机房，上海一位联通的用户访问我们的服务器，要先绕到联通的北京总出口（假设总出口在北京），然后再绕回上海。实际上这位联通用户可以通过上海的线路直接到达我们的服务器，不用绕这么远，但上海电信的机房无法告知联通的路由器走近路过来，只能按照联通路由器设定好的路由走。本来即使走北京绕一下也没有大的影响，毕竟是光的速度，但是由于大多数联通的用户访问电信网络都这么绕着走，联通的总出口成为了瓶颈，总出口流量太大时，联通的用户访问电信的网络速度就会慢。BGP线路也没什么神奇之处，只是它能决定走什么路由过来，不绕远路，问题自然解决了。它有这样的特权，就不仅能解决南北互通的问题，而且能解决其他网络的互通问题，比如教育网。因为有权限决定路由，就可以优化路由，哪条路堵，我就换条路。阿里云就是BGP线路，这就是我们的选择！      ​    钱也是我们要考虑的，普通租用机房一般是一年一结或者一季度一结。如果不是合作关系的话，过期没钱估计就直接掐断。。。而阿里云可以一月一结，甚至是按天，按配置，按流量收费。多种收费方法。增加了流动资金的同时，也可以随时增减配置和带宽，弹性伸缩，帮助网站运营。 上云前足足的功课 云计算是通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中，企业数据中心的运行将与互联网更相似。这使得企业能够将资源切换到需要的应用上，根据需求访问计算机和存储系统。 云计算特点如下：(1) 超大规模(2) 虚拟化(3) 高可靠性(4) 通用性(5) 高可扩展性(6) 按需服务(7) 极其廉价(8) 服务器级安全架构(9)快速搭建服务器(10)10分钟入门(12)智能工具(13)技术客服快速响应(14)7*24小时应用保障(15)云博士 一、云平台方案调研/技术选型国内云部分： 国外云部分 二、架构解析/优化阿里云的口号是：“打造数据分享的第一平台”。显然，做云计算只是一个起步。阿里巴巴在之前收购了万网，获得了相应的IDC运营资质和用户，也解决了IaaS、PaaS、SaaS领域了大部分问题，比如备案、域名注册、安全防护，用户群等等。 阿里云的运营方式跟微软与世纪互联合作，IBM与首都在线合作都是一个思路。这几家都是要踏踏实实做服务的，眼光不仅仅只是Web应用和移动应用，还包括了企业应用的范围。 以下是云计算常见的六种架构 1、云计算数据中心总体架构云计算架构分为服务和管理两大部分。在服务方面，主要以提供用户基于云的各种服务为主，共包含3个层次：基础设施即服务IaaS、平台即服务PaaS、软件即服务SaaS.在管理方面，主要以云的管理层为主，它的功能是确保整个云计算中心能够安全、稳定地运行，并且能够被有效管理。​ 2、云计算机房架构为满足云计算服务弹性的需要，云计算机房采用标准化、模块化的机房设计架构。模块化机房包括集装箱模块化机房和楼宇模块化机房。 3、云计算网络系统架构1)按照传送数据业务性质和面向用户的不同，网络系统可以划分为内部核心网、远程业务专网、公众服务网等区域。 2)按照网络结构中设备作用的不同，网络系统可以划分为核心层、汇聚层、接入层。 3)从网络服务的数据应用业务的独立性、各业务的互访关系及业务的安全隔离需求综合考虑，网络系统在逻辑上可以划分为存储区、应用业务区、前置区、系统管理区、托管区、外联网络接入区、内部网络接入区等。 4、云计算主机系统架构云计算核心是计算力的集中和规模性突破，云计算中心对外提供的计算类型决定了云计算中心的硬件基础架构。从云端客户需求看，云计算中心通常需要规模化的提供以下几种类型的计算力，其服务器系统可采用三(多)层架构，一是高性能的、稳定可靠的高端计算，主要处理紧耦合计算任务，这类计算不仅包括对外的数据库、商务智能数据挖掘等关键服务，也包括自身账户、计费等核心系统，通常由企业级大型服务器提供;二是面向众多普通应用的通用型计算，用于提供低成本计算解决方案，这种计算对硬件要求较低，一般采用高密度、低成本的超密度集成服务器，以有效降低数据中心的运营成本和终端用户的使用成本；三是面向科学计算、生物工程等业务，提供百万亿、千万亿次计算能力的高性能计算，其硬件基础是高性能集群。​ 5、云计算存储系统架构云计算采用数据统一集中存储的模式，在云计算平台中，数据如何放置是一个非常重要的问题，在实际使用的过程中，需要将数据分配到多个节点的多个磁盘当中。而能够达到这一目的的存储技术趋势当前有两种方式，一种是使用类似于GoogleFileSystem的集群文件系统，另外一种是基于块设备的存储区域网络SAN系统。​ 6、云计算应用平台架构云计算应用平台采用面向服务架构SOA的方式，应用平台为部署和运行应用系统提供所需的基础设施资源应用基础设施，所以应用开发人员无需关心应用的底层硬件和应用基础设施，并且可以根据应用需求动态扩展应用系统需的资源。 ​ 三、应用或数据库迁移过程/开发过程 1）首先进入阿里云官网注册阿里云帐号2）进入云服务器管理控制台，点击右上角的   创建实例   3）根据需要，自己选择计费方式等需要的项目阿里云服务器名词解释 Ⅰ）如果不知道自己想选什么地区的服务器，可以看看地域表。因为我这个项目是面向全球的，所以需要多个地区协作。同时注意，不同地域是不连通的。 Ⅱ）带宽方面，如果是小型网站，建议按量收费。大型网站，按固定带宽收费。至于带宽大小，自己算算就知道了。同时，阿里云免费提供最高 5Gbps 的恶意流量攻击防护。 Ⅲ）系统镜像方面 Windows 系统内含正版激活。       适合于运行Windows下开发的程序，如.net等。       支持SQL Server等数据库（需自行安装）。       以使用远程桌面方式登录进行管理。 Linux       最流行的服务器端操作系统，强大的安全性和稳定性。       免费且开源，轻松建立和编译源代码。       通过SSH方式远程访问您的云服务器。       一般用于高性能web等服务器应用，支持常见的PHP/Python等编程语言，支持MySQL等数据库（需自行安装)。       阿里云提供以下Linux操作系统：       CentOS （推荐） 请使用yum方式在线安装软件。       Ubuntu 请使用apt-get方式在线安装软件。       Debian 请使用aptitude方式在线安装软件。       Aliyun Linux 请使用yum方式在线安装软件。       CoreOS       FreeBSD       OpenSUSE       SUSE Linux ！ 香港、新加坡、美国地域的云服务器暂不支持 Linux 和 Windows 系统的互相更换，仅支持 Linux和Linux、Windows 和 Windows 同类型系统的更换。 Ⅳ）因为阿里云首次购买在部分地区好像有优惠。所以，要注意优惠，不要错过信息。像我选的这个套餐，便宜了非常多钱，这个在其他云不存在的。 Ⅴ）自己设置的用户名密码，务必记住。 注意事项： 快速入门(Linux) 快速入门(Windows) Windows2003环境安装包 Windows2008环境安装包 Linux环境安装包 我为什么要购买独立云磁盘？ 自动续费，减少用户人工续费的成本 上云方案实施 4）确认信息并且支付。 本来我是想装2003的，但是2003现在微软已经不提供更新和支持了，为了安全性，我选择了2008 R2 实例创建好之后，您会收到短信和邮件通知，告知您的实例名称、公网 IP 地址、内网 IP 地址等信息。您可以使用这些信息登录和管理实例。很多重要的信息都是通过绑定手机的短信接收，并且重要的操作（如重启、停止等）都需要手机接收验证码，因此请务必保持绑定手机通信畅通。 5）连接 Windows 实例Ⅰ）WINDOWS客户机按WIN+R运行mstsc Ⅱ）在 远程桌面连接 对话框中，输入实例的 IP 地址，单击 连接。  Ⅲ）输入密码后，你就拥有了第一台阿里云服务器了 Windows Server 2008 R2 的使用方法 Ⅳ）TIPs： 当普通远程连接软件（比如 Putty、Xshell、SecureCRT 等）无法使用时，您可以通过云服务器管理控制台的 远程连接 功能进入云服务器登录界面，查看服务器界面当时状态；如果您拥有操作权限，可以登录到服务器进行操作配置，对于有技术能力的用户解决自己遇到的问题有很大的帮助Ⅴ）0M带宽实例管理方法Ⅵ）如果您在创建实例时选择了数据盘，在登录实例后，系统需要先格式化数据盘。如果没有购买数据盘，可以跳过此步骤。 Ⅶ）格式化完成后，您可以通过 服务器管理器 > 文件和存储服务 > 卷 > 磁盘 来查看该实例中所有的磁盘。Ⅷ）然后，你就可以自由地使用你的服务器了。如果发现IIS或者MYSQL未安装，可以参考win2008 php运行环境搭建图文教程 6）键入代码及保存测试这里的代码是Single File.PHP的代码。本地化（相对连接）的代码请进入https://github.com/kajweb/ESC查看 <?PHP////////--------https://github.com/kajweb/ESC-----------////// $Address_Data = GetADD();//调用获取地点数据if($Address_Data['country'] == '中国') $Address_Data['country']="";//如果国家是中国，则地名不显示中国。如果是其他国家则正常显示if($Address_Data['province'] == $Address_Data['city'])$Address_Data['city']="";//如果省份和城市相同、则只显示一个$User_Address = $Address_Data['country'].$Address_Data['province'].$Address_Data['city'];//将地区信息储存在$User_Address中if(empty($Address_Data['ip'])){$Address_Data['ip'] = "您";$User_Address = "你那里";}//错误处理，加入获取不了IP的处理方式 function GetADD($ip = ''){ if(empty($ip)){ $ip =$_SERVER["REMOTE_ADDR"]; } $res = @file_get_contents('http://int.dpool.sina.com.cn/iplookup/iplookup.php?format=js&ip=' . $ip); //经测试@file_get_contents可用，不必使用cURL if(empty($res)){ return false; } $jsonMatches = array(); preg_match('#\{.+?\}#', $res, $jsonMatches); if(!isset($jsonMatches[0])){ return false; } $json = json_decode($jsonMatches[0], true); if(isset($json['ret']) && $json['ret'] == 1){ $json['ip'] = $ip; unset($json['ret']); }else{ return false; } return $json; }?> <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>祝阿里云越办越好</title> <script type="text/javascript" src="http://t.cn/RJibm1T?aliyunCDN of jquery.min.js"></script> <script type="text/javascript" src="http://t.cn/RJiqZN6?aliyunCDN of jscex.min.js"></script> <script type="text/javascript" src="http://t.cn/RJiGsGK?aliyunCDN of jscex-parser.js"></script> <script type="text/javascript" src="http://t.cn/RJiGBXw?aliyunCDN of jscex-jit.js"></script> <script type="text/javascript" src="http://t.cn/RJiG0Nw?aliyunCDN of jscex-builderbase.m.js"></script> <script type="text/javascript" src="http://t.cn/RJiGt8T?aliyunCDN of jscex-async.min.js"></script> <script type="text/javascript" src="http://t.cn/RJiG26P?aliyunCDN of jscex-async-powerpa.js"></script> <script type="text/javascript" src="http://t.cn/RJibM8S?aliyunCDN of functions.js" charset="utf-8"></script> <script type="text/javascript" src="http://t.cn/RJiq5cM?aliyunCDN of love.js"></script> <link rel="stylesheet" href="http://t.cn/RJiqXdh?aliyunCDN of main.css" type="text/css" /> </head> <body> <audio autoplay="autopaly"> <source src="http://t.cn/RJiUnop?aliyunCDN of BGM" type="audio/mp3"> </audio> <div id="main"> <div id="error">本页面采用HTML5，很遗憾你的浏览器不支持本页面，请换成其他浏览器，或者更新到最新版本。</div> <div id="wrap"> <div id="text"> <div id="code"> <font color="#FF0000"> <span class="say">亲爱的用户:<br> 您好!</span><br> <span class="say"> </span><br> <span class="say"> <b><?php echo $User_Address?></b>好玩吗？我一直想去，</span><br> <span class="say"> </span><br> <span class="say">可是，自从<B>2009年09月10号。</B></span><br> <span class="say"> </span><br> <span class="say">阿里云成立，</span><br> <span class="say">就必须无时无刻地为programmer服务。</span><br> <span class="say">我不能走开，一步也不可以。 </span><br> <span class="say">我的目的是，为大家提供优质的服务。 </span><br> <span class="say"> </span><br> <span class="say"><span class="space"></span> -- 一个无名的Coder--</span><br> <span class="say"></span><br><br> <span class="say">对<?php echo $Address_Data['ip'] ?>表示最真挚的问候~~</span> </font> <p></p> </div> </div> <div id="clock-box"> <span class="STYLE1"></span><font color="#33CC00">亲爱的用户，阿里云</font> <span class="STYLE1">已经<font color="red">稳定</font>运营了</span> <div id="clock"></div> </div> <canvas id="canvas" width="1100" height="680"></canvas> </div> <script type="text/javascript" src="http://t.cn/RJiq0uF?aliyunCDN of main.js"></script> </div> </body> 7）效果预览  点击体验  四、遇到的问题及解决方案 【遇到问题1】关于免费体验 【解决方案1】免费体验本来呢，想免费体验一下阿里云的。但是非常不幸运的是注册后还需要老用户的邀请码（LV3,LV4）才能有资格，而且还要满足一定的条件：满足如下规则的用户，可通过以下方式获取免费套餐资格： 通过个人&企业实名认证 个人用户芝麻信用分≥620分 从未购买过阿里云产品（域名、邮箱除外）可以我没有认识这些老用户啊。So，砸钱进去。毕竟一分钱一分货。当冲钱进去后，你不会后悔你冲过的钱的，因为阿里云的质量是值得信赖的！ 【遇到问题2】GitHub代码上传失败【解决方案2】在GitHub GUI中选中图中的选项强制上传 【遇到问题3】关于PHP获取IP【解决方案3】通过查找资料，总结了PHP获取IP地址的6种方法，具体使用，请各位读者自己尝试。本文使用的是方法3<?php//方法一：function GetIP(){if(!empty($_SERVER["HTTP_CLIENT_IP"])){ $cip = $_SERVER["HTTP_CLIENT_IP"];}elseif(!empty($_SERVER["HTTP_X_FORWARDED_FOR"])){ $cip = $_SERVER["HTTP_X_FORWARDED_FOR"];}elseif(!empty($_SERVER["REMOTE_ADDR"])){ $cip = $_SERVER["REMOTE_ADDR"];}else{ $cip = "无法获取！";}return $cip;}echo GetIP();?> <?php//方法二：error_reporting (E_ERROR | E_WARNING | E_PARSE);if($HTTP_SERVER_VARS["HTTP_X_FORWARDED_FOR"]){$ip = $HTTP_SERVER_VARS["HTTP_X_FORWARDED_FOR"];}elseif($HTTP_SERVER_VARS["HTTP_CLIENT_IP"]){$ip = $HTTP_SERVER_VARS["HTTP_CLIENT_IP"];}elseif ($HTTP_SERVER_VARS["REMOTE_ADDR"]){$ip = $HTTP_SERVER_VARS["REMOTE_ADDR"];}elseif (getenv("HTTP_X_FORWARDED_FOR")){$ip = getenv("HTTP_X_FORWARDED_FOR");}elseif (getenv("HTTP_CLIENT_IP")){$ip = getenv("HTTP_CLIENT_IP");}elseif (getenv("REMOTE_ADDR")){$ip = getenv("REMOTE_ADDR");}else{$ip = "Unknown";}echo $ip;?> <?php//方法三：$iipp = $_SERVER["REMOTE_ADDR"];echo $iipp ;?> <?php//方法四：$user_IP = ($_SERVER["HTTP_VIA"]) ? $_SERVER["HTTP_X_FORWARDED_FOR"] : $_SERVER["REMOTE_ADDR"];$user_IP = ($user_IP) ? $user_IP : $_SERVER["REMOTE_ADDR"];echo $user_IP?> <?php//方法五：function get_real_ip(){$ip=false;if(!empty($_SERVER["HTTP_CLIENT_IP"])){ $ip = $_SERVER["HTTP_CLIENT_IP"];}if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])){ $ips = explode (", ", $_SERVER['HTTP_X_FORWARDED_FOR']); if($ip){ array_unshift($ips, $ip); $ip = FALSE; } for($i = 0; $i < count($ips); $i++){ if (!eregi ("^(10|172.16|192.168).", $ips[$i])){ $ip = $ips[$i]; break; } }}return($ip ? $ip : $_SERVER['REMOTE_ADDR']);}echo get_real_ip();?> <?php//方法六：if(getenv('HTTP_CLIENT_IP')){$onlineip = getenv('HTTP_CLIENT_IP');}elseif(getenv('HTTP_X_FORWARDED_FOR')){$onlineip = getenv('HTTP_X_FORWARDED_FOR');}elseif(getenv('REMOTE_ADDR')){$onlineip = getenv('REMOTE_ADDR');}else{$onlineip = $HTTP_SERVER_VARS['REMOTE_ADDR'];}echo $onlineip;?> 【遇到问题4】关于通过IP获取具体城市的API【解决方案4】在实际应用中，发现许多通过IP获取具体城市的API不能正常使用的。后来通过网上帖子的分析与论证，发现了该接口。当写完后，发现阿里云市场也有。但是，人懒，能用就行了 ！所以就没改。其实，我们也可以用过自己创建IP段的形式写IP库，但是，懒！调用云服务就可以了。 【遇到问题5】其他代码类问题【解决方案5】可以进入阿里云工单系统，点击  提交工单   然后就可以问萌萌的客服问题了 五、上云前后分析对比 1）一站式服务建设一个网站需要域名、空间、数据库等。阿里巴巴网络有限公司（HK.1688）（2009年9月28日）宣布，将支付人民币5.40亿元的现金，分两期获得国内领先的互联网基础设施服务提供商中国万网在中国营运的股权，以加速协助小企业客户由“meet at alibaba”迈向“work at alibaba”的十年愿景战略部署。 从此不用域名一个服务商，空间一个IDC，数据库一个服务商了。2）一站式备案以前采用普通主机，备案需要走来走去，自从有了阿里云，阿里云拥有完善的备案系统https://beian.aliyun.com 通过这个系统，方便简介地备案。 3）弹性伸缩根据业务需求和策略，自动调整其弹性计算资源的管理服务，在满足业务需求高峰增长时无缝地增加ECS实例，并在业务需求下降时自动减少ECS实例以节约成本。 4）容器服务容器服务（Container Service）提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过 Docker 容器来进行应用生命周期管理。容器服务极大地简化了用户对容器管理集群的搭建工作，无缝整合了阿里云虚拟化、存储、网络和安全能力，打造 Docker 云端最优化的运行环境。容器服务提供了多种应用发布方式和流水线般的持续交付能力，原生支持微服务架构，助力用户无缝上云和跨云管理。 5）批量计算批量计算（BatchCompute）是一种适用于大规模并行批处理作业的分布式云服务。BatchCompute可支持海量作业并发规模，系统自动完成资源管理，作业调度和数据加载，并按实际使用量计费。 6）CDNCDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。7）对象存储 OSS阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以通过调用 API，在任何应用、任何时间、任何地点上传和下载数据，也可以通过 Web 控制台对数据进行简单的管理。OSS 适合存放任意类型的文件，适合各种网站、开发企业及开发者使用。按实际容量付费真正使您专注于核心业务。 8）负载均衡及后端数据同步阿里云由于使用rsync等同步软件进行实时数据同步。所以，阿里云建议用户将负载均衡后端所有ECS配置成无状态的应用服务器，将数据和文件统一存放在后端RDS和OSS等公共服务上。 9）API 网关阿里云拥有完善的API，可以提供高性能、高可用的 API 托管服务，帮助用户对外开放其部署在 ECS、容器服务等阿里云产品上的应用，提供完整的 API 发布、管理、维护生命周期管理。用户只需进行简单的操作，即可快速、低成本、低风险地开放数据或服务。 10）服务器安全及抵抗高流量攻击Ⅰ）云盾当受到攻击时，流量会经过云盾节点，并触发清洗机制，起到CC/DDoS防护作用。 Ⅱ）加密服务加密服务(Data Encryption Service)是云上的加密解决方案。服务底层使用经国家密码管理局检测认证的硬件密码机，通过虚拟化技术，帮助用户满足数据安全方面的监管合规要求，保护云上业务数据的隐私性要求。借助加密服务，用户能够对密钥进行安全可靠的管理，也能使用多种加密算法来对数据进行可靠的加解密运算。 Ⅲ）DDoS 基础防护 & DDoS 高防IP阿里云免费为用户提供最高5G的默认DDoS防护能力。阿里云在此基础上，推出了安全信誉防护联盟计划，将基于安全信誉分进一步提升DDoS防护能力，用户最高可获得100G以上的免费DDoS防护资源。 云盾DDoS高防IP是针对互联网服务器（包括非阿里云主机）在遭受大流量的DDoS攻击后导致服务不可用的情况下，推出的付费增值服务，用户可以通过配置高防IP，将攻击流量引流到高防IP，确保源站的稳定可靠。 Ⅳ）阿里绿网阿里绿网基于深度学习技术及阿里巴巴多年的海量数据支撑， 提供多样化的内容识别服务，能有效帮助用户降低违规风险。目前已开放网站内容检测和图片鉴黄服务，后续还会推出垃圾广告过滤、图文识别、视频识别等服务。另外我们拥有业内顶尖的算法专家，丰富的内容识别经验，同时为阿里集团全网（含蚂蚁集团）提供内容识别服务，产品也在快速迭代中。 Ⅴ）证书服务云盾证书服务(Alibaba Cloud Certificates Service)是阿里云联合若干国内外知名CA证书厂商，在阿里云平台上直接提供服务器数字证书，阿里云用户可以在云平台上直接购买甚至免费获取所需类型的数字证书，一键部署在阿里云产品中，最小成本的将所持服务从HTTP转换成HTTPS。Chrome从2017年10月起将要求遵守证书透明 Ⅵ）云盾混合云云盾混合云以阿里云互联网攻防技术为核心，能够为用户建设涵盖网络安全、应用安全、主机安全、安全态势感知的全方位互联网安全攻防体系。不同于以往以检测技术为主的边界防护方式，云盾.混合云防护以泛安全数据与情报联动分析为驱动，为用户提供全景的安全态势感知、攻击溯源回溯、基础安全防护等功能。通过纯软件化的部署方式，云盾.混合云能够使得用户在自有IDC、私有云、公有云、混合云等多种业务环境获得与阿里云同等强度的互联网防护能力。 Ⅶ）漏洞扫描 六、借助阿里云国际版布局海外市场的经验 阿里云国际业务总经理喻思成2016年8月在大会上表示，“过去一年里，有数万中国企业使用阿里云海外基础设施来拓展业务，全球一张网的数据中心布局为企业们节省了逾百亿的出海成本。” ，基于阿里云全球化的数据中心布局，中国企业可以将拓展拓展海外业务的时间从原本数月缩短至几分钟，“原来企业们需要在当地雇员搭建自己的计算资源，现在在国内就可以即开即用，用一张云计算网络支撑全球业务。” 1）地域列表 可用区（Zone） 可用区是指在同一地域内，电力和网络互相独立的物理区域。同一可用区内的 ECS 实例网络延时更小。 ·在同一地域内可用区与可用区之间内网互通，可用区之间能做到故障隔离。是否将云服务器 ECS 实例放在同一可用区内，主要取决于对容灾能力和网络延时的要求。 ·如果您的应用需要较高的容灾能力，建议您将云服务器 ECS 实例部署在同一地域的不同可用区内；如果您的应用在实例之间需要较低的网络时延，则建议您将 ECS 实例创建在相同的可用区内。2）全球节点无缝覆盖 3）一键控全球，免备案 4）高速跨境网络优势 5）阿里云和亚马逊云详细对比 6）中国客户购买海外资源常见问题FAQ点击浏览阿里云帮助文档 七、其他人的上云经验 【Q】为什么成千上万的客户信任阿里云？【A】阿里云正在为千万开发者提供全球领先的云计算服务平台，可弹性扩展、安全稳定、简单易用。 安全稳定 弹性扩展 节约成本 快速运维 八、引用 点击体验本文实例 浅析云计算的六种架构 html5唯美表白 关于杭州市网站公安备案公告 九、选云总结   经过这次选型，我确定云计算是未来服务器的首选，并确定了阿里云在云计算的领先地位。同时也确定了阿里云对个人、企业具有重要意义，是一个可靠的云服务商。 通过上云，不仅仅是拥有了可靠的性能，还拥有了稳定的弹性伸缩。 纸上谈兵终觉浅，但是对于新鲜实物的尝试，也需要做足功课，对整体的云市场、操作环境、案例、遇到问题与解决有一个详细的了解，相信和我一样慎重的人，大有人在，也希望此篇分享，可以对即将上云的您有一定的参考，在上云后的日子，还有很多未知的难题，相信今后还会有更多问题交流解决与大家一起学习与分享！

每期阿里云的技术分享课程都报名火爆，各路技术大咖进行了对于技术理解的深度分享，但是还是有很多小伙伴错过了现场直播。本文特意为大家整理了阿里云在线技术分享课程的精彩合集，错过了直播的小伙伴们快来补补课吧！ 12月28日 阿里沈询：分布式事务原理与实践 分布式数据库之中，一个最重要待解决的问题就是分布式事务应该怎么支持。往往一提到分布式事务，就立刻会联想到性能低，速度慢，然而真的是这样么？有没有一些方式和方法，能够比较好的解决这个问题呢？阿里针对这个场景又是怎么去实践的呢？阿里中间件资深技术专家沈询，将于12月28日20:00做客云栖直播，为大家深度分享《分布式事务原理与实践》。 12月27日  从互联网安全到IoT安全，如何关上潘多拉魔盒？ 在即将到来的万物互联时代，物联网安全领域还有哪些重磅炸弹爆出？它和互联网安全有什么区别？近期这些安全事件本质是什么？各大厂商又该如何应对？几位阿里安全专家将为大家分享。 12月22日 阿里云大学美女院长：畅聊直播与云计算 阿里云大学美女院长安宁将带领大家一起探究云计算的前世今生以及视频直播的那些事。 12月21日 BUY+和造物神 想像一下，你坐在沙发上，一边品尝着咖啡，一边戴着VR头盔，穿梭于世界各地的百货商店。这样的实景购物体验是不是很过瘾呢？高大上的VR、AR技术已经让普通用户体验到更多的生活乐趣。天猫双十一活动已经举行了八年，每年都会注入黑科技以提升用户体验。2016年首先是AR活动预热，“寻找狂欢猫”活动启动,然后BUY+购物上线。本期邀请嘉宾带你走进购物“任意门”背后的技术世界。 12月21日 混合云实战（下）：手把手教你组建混合云网络 阿里云推出专有网络VPC，为用户上云提供超强的安全隔离保障，让您再也不必担心云上多租户环境所带来的安全隐患。然而，拥有自建IDC的用户希望把云作为新的IDC，如何才能够安全可靠、低成本、高质量的平滑迁移上云？今天，我们将面对面教会大家如何利用阿里云的产品构建混合云，使得云上云下数据互通。 12月15日 混合云实战（上）：手把手教你组建混合云网络 阿里云推出专有网络VPC，为用户上云提供超强的安全隔离保障，让您再也不必担心云上多租户环境所带来的安全隐患。然而随着用户业务扩大，在不同的国家、不同的节点下都部署有多个VPC，如何才能使这些VPC之间能够拥有高质量的通信？拥有自建IDC的用户如何才能够安全可靠、低成本、高质量的平滑迁移上云？本次将与大家分享如何构建融合网络，并面对面教会大家如何在阿里云控制台上轻松实现VPC之间的互联。 12月14日 Docker深度实践 Docker和容器服务让我们可以专注应用本身功能的开发，而无需关注基础设施、应用部署、管理等等一大堆棘手的问题。越来越多的公司开始使用Docker，以降低运维的成本。掌握Docker方能用好Docker，想了解 Docker镜像原理、镜像构建的最佳实践？想知道应用容器化的正确姿势？想深入Docker底层网络?本期云栖Techday将为您一一道来。 12月14日 阿里HotFix2.0升级详解——技术运营小二畅谈热修复领域那些事 热修复领域充斥着各大流派，如阿里AndFix、美团Robust、微信Tinker等，每种方法各有优劣。本文介绍的百川Hotfix 2.x是在1.x版本进行了优化和创新，不仅支持灵活切换热部署和冷部署的方案；实现了资源、SO文件、类修复的实时生效；接入时不侵入打包过程，并为用户提供了可视化的UI界面。 12月13日 伏羲—阿里云分布式调度系统 在云栖社区在线培训上，“飞天”分布式系统核心开发人员陶阳宇分享了《伏羲-阿里云分布式调度系统》。他主要从伏羲系统架构、任务调度、资源调度、容错机制、规模挑战、安全与性能隔离方面介绍了伏羲分布式系统架构和设计理念。 12月8日 剖析美国大选幕后的大数据真相 美国大选已经“完美落幕”，但是关注技术的我们更关心这场大选背后的操盘手——大数据。 说起来，大数据已经悄然渗透到我们生活的方方面面了，但很多人依然不能察觉。这次，我们就邀请到阿里云大数据学院院长宁尚兵老师为我们直播讲述，大数据是怎样“侵入”我们的生活、它在政治、经济、商业模式等方面怎样施展拳脚以及大数据这个行业是怎样发展的。 对于想从事相关工作的朋友来说，这是一堂非常全面的入门课程；对于其他人来说，宁老师的“段子式直播”也会为你积累许多有趣有料的谈资。 12月5日  赢了围棋后，人工智能离看病还有多远？ 人工智能在医疗领域能做什么？前景如何？在实际应用场景中，哪个能率先获得突破？大医疗大健康延展来看，在智能陪护和养老等领域，人工智能会有哪些价值？同时，几位专家也会深入现状和问题中寻求解决办法，比如面对医疗数据总量不足、质量不高的情况下，如何开展医疗的人工智能？医疗数据涉及患者隐私，应该如何去解决？本视频进行了解读。 12月1日 美女程序媛和你聊：云栖大会护航幕后故事 本期云栖说，邀请到了杭州云栖大会技术护航团队成员深度分享直播护航背后的技术和故事，分别是：夸父，阿里云应用运维专家，醒玳，阿里云资深技术支持，保障过千余场视频直播活动，多次参与大型直播场景质量调优与架构分析，支持的客户代表：芒果TV、新浪微博，明稀，阿里云资深技术支持，为多家企业客户提供专属技术支持服务，专精于网络、系统、高可用架构实施，支持的客户代表有UC、熊猫TV、BILIB，宁克凡，目睹直播技术总监，多年后端架构经验，擅长Web性能调优、微服务化构建。 12月30日 Redis内核优化最佳实践 Redis作为一个内存数据库，也提供了数据持久化的机制用于数据恢复，但是当客户希望能像RDS一样做基于时间点的数据恢复时，原生的持久化机制就无能为力了。此外，Redis的主从同步机制在写入流量很高或网络抖动时，很容易导致全量同步，而全量同步带来的风险是非常高的。本次议题就围绕如何在Redis上支持基于时间点的备份恢复，以及如何尽量避免全量同步这个问题来展开进行分享。 11月29日 云解析大学第一期：DNS安全之道 11月29日云栖社区在线培训，云栖社区请来了阿里巴巴基础架构事业群技术专家宋毅给大家带来了DNS安全之道的讲解。本文主要从介绍云解析DNS开始，详细分析了DNS的总技术架构，接着分享了权威解析系统和安全解析系统，最后与大家介绍了云解析高级功能，包括基础解析和智能解析等。一起来了解下吧。 11月24日 女娲：阿里云高性能、高可扩展的分布式一致性服务 女娲（Nuwa）是阿里云飞天系统底层核心模块之一。从2009年飞天建立起开始自主开发，Nuwa对基于飞天的系统提供一致性、分布式锁、消息通知等服务。和有类似功能的开源软件相比，Nuwa在性能，可扩展性和可运维性上有明显优势。Nuwa在阿里云支持着MaxCompute/ECS/TableStore/OSS等重量级基于飞天系统的云产品。本次分享主要介绍女娲的服务架构等内容。 11月23日 玩转ECS云服务器：第一期“走进块存储产品” 云服务器 （ECS）是阿里云提供的一种基础云计算服务，用户可以根据业务需要，随时创建所需数量的云服务器实例，并在使用过程中，随着业务的变化，对云服务器进行资源扩容、升降配置或资源释放等操作。本期将会为您介绍块存储产品的基本特性和使用方法。 11月 《深入浅出Node.js》作者分享：Node.js应用性能监控与问题诊断 在阿里云云栖社区举办的在线培训中，来自阿里云飞天八部alinode团队的开发专家田永强（朴灵）带来了题为《Node.js应用性能监控与问题诊断》的精彩分享。本次分享主要议程包括：Node.js的优势与劣势、常见的性能调优和故障排查方法、alinode与常见APM的区别以及如何使用alinode进行故障定位和性能调优。 10月 App全量混淆和瘦身技术揭秘 为了解决安卓App容易被逆向的问题，除了对产品进行加固处理，代码混淆技术是对抗逆向攻击最有效的方式之一。本直播会分享阿里聚安全带来的APP全量混淆技术。此外越来越多的新特性正在啃蚀着大型App的用户体验，App瘦身减肥也成了亟待解决的问题,如何能在使用安全功能同时瘦身，也将是本期主题所带来的内容。 10月23日 阿里云SDN/NFV之架构与实践 来自阿里云网络产品团队孙成浩（花名：梵叶）分享了《阿里云SDN/NFV之架构与实践——一次自然的技术演进》。作为网络产品团队中负责产品相关的技术架构架构师，他结合阿里云的网络云产品探讨了阿里云虚拟网络的网络技术架构，并且结合SDN和NFV分享了阿里云的思考和实践。 10月 Python+大数据计算平台，PyODPS架构手把手教你搭建 阿里云大数据事业部的秦续业分享了《双剑合壁——Python和大数据计算平台的结合实战》。他主要介绍了数据分析和机器学习的方法、DataFrame整体架构以及基础API、前端、后端、机器学习的具体实现方法。 10月19日 盘古：阿里云飞天分布式存储系统设计深度解析 盘古是一个分布式文件系统，在整个阿里巴巴云计算平台“飞天”中，它是最早被开发出的服务。在“飞天”平台中，它是负责数据存储的基石性系统，其上承载了一系列的云服务。盘古的设计目标是将大量通用机器的存储资源聚合在一起，为用户提供大规模、高可用、高吞吐量和良好扩展性的存储服务。本次分享，将会为大家介绍一下阿里云盘古系统，并分享盘古作为大规模通用存储面临的问题和解决方案。 10月 业务需要全球部署？来看看企业级全球网络架构与解决方案 阿里云的企业级网络产品经理李泉带来了《企业级全球网络架构和解决方案》的分享，分享中他主要从企业级全球网络、典型场景与方案、典型案例三个方面介绍了阿里云企业级全球网络架构与解决方案。 10月 直播兴起的军功章上也有你的一半——Redis实践及在直播行业的应用 阿里云数据库技术组的白宸为听众带来了题为《Redis实践及在直播行业的应用》的分享，本次直播包括Redis介绍、直播行业介绍、Redis应用场景、云数据库Redis设计、云数据库Redis实践五部分。 10月 超大型系统的持续集成与持续交付解决方案与阿里宙斯盾 敏捷研发模式在小型团队中能够帮助开发人员进行快速迭代开发，但是对于大型团队而言，敏捷研发模式却并不能发挥应有的效果。那么如何实现超大型系统的持续集成与持续交付呢？ 9月 八大案例，带你参透SQL Server优化 在本文中，石沫针对用户遇到的各种实际问题，从实例层次到架构，通过8个SQL Server优化案例，分享了如何用最简单快捷的方式解决用户使用SQL Server数据库过程中的典型问题，使SQL Server能够稳定地提供持续服务。 6月23日 铁庵：NoSQL、RDS和大数据异构融合实战，详解PostgreSQL FDW功能原理 阿里云的ApsaraDB数据库产品专家萧少聪(铁庵)与大家分享了通过PostgreSQL实现NoSQL、RDS和大数据异构融合实战。直播中，他重点介绍FDW原理，并结合金融报文处理、物联网数据整合、企业并购重组场景下的具体案例，详细讲解了PostgreSQL是如何通过FDW外部数据通道功能实现NoSQL、大数据异构融合以及开发效率的提升的。 5月27日 德歌：阿里云RDS PG最佳实践 阿里云的高级技术专家德歌与大家分享阿里云云数据库PostgreSQL的最佳技术实战，包括上云实战、数据迁移与同步、阿里云RDS相关周边组件用法、插件使用等内容。 5月 “技术女神”清宵：云存储之基本技巧和上云实践 大咖秀：阿里“技术女神”清宵来啦！想知道阿里云存储业务的相关产品和技术特点，业务解决构架和解决方案的具体细节么？快快搬着你的小板凳，看清宵妹子的分享吧！ 5月 虎嗅：四年覆盖9成互联网企业中高层的网站架构演变 在本次分享中，虎嗅网联合创始人韩祖利将为大家分享虎嗅网云上架构实践经验，包括如何打造高效图片系统、如何做好主动式缓存管理，以及云服务使用经验。同时，也会从一个老司机的角度分享如何做好系统架构设计。 4月27日 21天搭建推荐系统：实现“千人千面”个性化推荐 2016云栖大会南京峰会上，阿里云算法专家、阿里云推荐引擎技术负责人郑重（卢梭）为大家分享了“21天搭建推荐系统”，这次分享得到了大家的积极反馈。因此，云栖社区邀请卢梭做客云栖社区，在6月16日晚8点在线再次分享《21天搭建推荐系统》。 4月 访谈：脸萌团队的分布式数据库实践 在本次分享中，脸萌CTO王中飞将为大家分享脸萌团队新产品Faceu在分布式数据库方面的技术实战，比如为何选择DRDS、使用DRDS中的一些经验。阿里云DRDS产品经理也会为大家介绍DRDS背后的故事与技术沉淀。DRDS前身为淘宝TDDL，是近千核心应用首选组件，已在阿里内部稳定服务8年以上。 4月15日 阿里云RDS MySQL分支深度定制实战分享 阿里云RDS MySQL经过多年的积累，不断的进行性能优化，并定制了适合不同行业需求的功能，同时也向官方和社区贡献我们的力量。本次主题主要介绍RDS MySQL分支的深度定制，包括功能扩展、资源管控、性能优化、数据安全、行业解决方案等。 3月30日 揭秘微博实现分钟级服务器成倍扩容 每逢重要节日，微博流量会出现暴涨，2016年春晚，微博日活跃用户达到1.34亿，比去年除夕增长31%。在如此大访问量的情况下，后端服务的稳定性和性能保障任务艰巨。本次重点分享微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括Docker与虚机结合的使用经验、网络架构以及负载均衡等。 3月29日  基于混合云架构的高可用实践 随着整体业务的高速发展、流量的爆发式增长，有货对其系统做了大面积的系统重构，首先数据中心从传统的单一IDC到“公共云+IDC”混合模式；应用系统也从原来的单体的全站应用演变到目前的以微服务为核心的架构模式；同时采取多级缓存、服务的降级等多维度、全方面地提升系统的可用性。 3月25日 混合云架构与大数据服务实践 本次美柚带来的分享包括如何充分利用现有机房服务器资源与阿里云产品组建混合云架构，实现快速部署与大数据的处理与计算服务。同时也详细介绍了美柚在多维度用户数据分析处理和大数据智能挖掘技术的实践经验。 3月23日 云上架构设计及轻运维监控经验 本次分享主要介绍涂鸦科技云上架构设计和借助阿里云实现轻运维高可用性监控的实战经验，同时也介绍了网络安全、权限控制等特定场景下如何利用阿里云产品解决特定的问题。 3月18日 小咖秀产品服务端架构设计分享 小咖秀的张华伟带来的分享是在移动互联网时代，创业团队在技术储备、经验积累以及资金等有限的情况下，怎样选择合适的服务端技术解决突发式流量增长所带来的压力以及最大化节省运营成本等方面的经验和建议。同时也对划分URL目录，合理使用缓存等问题给出自己独特的答案。 3月16日 空格技术架构云上实践与经验 空格APP上线仅仅60天就获得1亿A轮融资，同时依靠阿里云只用了两个礼拜就实现了APP上线。空格技术合伙人刘博本次分享主要介绍了阿里云在空格内的应用经验包括服务端整体架构的搭建和搜索、推荐和数据平台业务场景下的实践探索。 3月11日 基于混合云的OTA比价系统、精准运营和大数据用户推荐 驴妈妈技术副总邵汉成本次分享主要内容包括驴妈妈旅游网的整体系统发展历程、服务治理和数据库分库经验、基于混合云的产品数据分析系统。驴妈妈旅游网利用混合云方案极大提高了整体架构的弹性扩展，同时又满足了快速发展的业务需求，进一步提升精准运营并提升产品竞争力。 3月4日 游族网络：我们是怎么玩转千台以上游戏云服务器的 来自上海游族网络的运维总监李志勇，带来的分享“如何运维千台以上游戏云服务器”，本次分享中重点是云时代的运维，包括游戏上云部署整体方案、游戏服务器批量运维管理，并对企业选择RDS还是自建MySQL数据库给出了自己建议。

当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。 Web负载均衡 Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。 负载均衡的策略有很多，我们从简单的讲起哈。 1. HTTP重定向 当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302，如下图： 亿级Web系统搭建——单机到分布式集群 – hansionxu – 技术的天空 如果使用PHP代码来实现这个功能，方式如下： 这个重定向非常容易实现，并且可以自定义各种策略。但是，它在大规模访问量下，性能不佳。而且，给用户的体验也不好，实际请求发生重定向，增加了网络延时。 2. 反向代理负载均衡 反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。 Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。 解决方案主要有两种： 配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。 将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。 反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。 3. IP负载均衡 IP负载均衡服务是工作在网络层（修改IP）和传输层（修改端口，第四层），比起工作在应用层（第七层）性能要高出非常多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），通过IPVS（IP Virtual Server，IP虚拟服务）来实现。 在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，然后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。 上述的方式叫LVS-NAT，除此之外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，但是有一定的区别，篇幅问题，不赘叙。 IP负载均衡的性能要高出Nginx的反向代理很多，它只处理到传输层为止的数据包，并不做进一步的组包，然后直接转发给实际服务器。不过，它的配置和搭建比较复杂。 4. DNS负载均衡 DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。 这种负载均衡策略，配置简单，性能极佳。但是，不能自由定义规则，而且，变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。 5. DNS/GSLB负载均衡 我们常用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，通过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。一般情况下都是按照地理位置，将离用户近的IP返回给用户，减少网络传输中的路由节点之间的跳跃消耗。 图中的“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），然后得到指定域名的授权DNS，然后再获得实际服务器IP。 CDN在Web系统中，一般情况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽可能离用户更近，提升用户体验。 例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的原因是防止http请求的时候，带上了多余的cookie信息），我获得的IP是183.60.217.90。 这种方式，和前面的DNS负载均衡一样，不仅性能极佳，而且支持配置多种策略。但是，搭建和维护成本非常高。互联网一线公司，会自建CDN服务，中小型公司一般使用第三方提供的CDN。 Web系统的缓存机制的建立和优化 刚刚我们讲完了Web系统的外部网络环境，现在我们开始关注我们Web系统自身的性能问题。我们的Web站点随着访问量的上升，会遇到很多的挑战，解决这些问题不仅仅是扩容机器这么简单，建立和使用合适的缓存机制才是根本。 最开始，我们的Web系统架构可能是这样的，每个环节，都可能只有1台机器。 我们从最根本的数据存储开始看哈。 一、 MySQL数据库内部缓存使用 MySQL的缓存机制，就从先从MySQL内部开始，下面的内容将以最常见的InnoDB存储引擎为主。 1. 建立恰当的索引 最简单的是建立索引，索引在表数据比较大的时候，起到快速检索数据的作用，但是成本也是有的。首先，占用了一定的磁盘空间，其中组合索引最突出，使用需要谨慎，它产生的索引甚至会比源数据更大。其次，建立索引之后的数据insert/update/delete等操作，因为需要更新原来的索引，耗时会增加。当然，实际上我们的系统从总体来说，是以select查询操作居多，因此，索引的使用仍然对系统性能有大幅提升的作用。 2. 数据库连接线程池缓存 如果，每一个数据库操作请求都需要创建和销毁连接的话，对数据库来说，无疑也是一种巨大的开销。为了减少这类型的开销，可以在MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候，再创建，空闲过多的时候，则销毁。 其实，还有更为激进一点的做法，使用pconnect（数据库长连接），线程一旦创建在很长时间内都保持着。但是，在访问量比较大，机器比较多的情况下，这种用法很可能会导致“数据库连接数耗尽”，因为建立连接并不回收，最终达到数据库的max_connections（最大连接数）。因此，长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务，控制CGI机器“盲目”创建连接数。 建立数据库连接池服务，有很多实现的方式，PHP的话，我推荐使用swoole（PHP的一个网络通讯拓展）来实现。 3. Innodb缓存设置（innodb_buffer_pool_size） innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区，如果机器是MySQL独占的机器，一般推荐为机器物理内存的80%。在取表数据的场景中，它可以减少磁盘IO。一般来说，这个值设置越大，cache命中率会越高。 4. 分库/分表/分区。 MySQL数据库表一般承受数据量在百万级别，再往上增长，各项性能将会出现大幅度下降，因此，当我们预见数据量会超过这个量级的时候，建议进行分库/分表/分区等操作。最好的做法，是服务在搭建之初就设计为分库分表的存储模式，从根本上杜绝中后期的风险。不过，会牺牲一些便利性，例如列表式的查询，同时，也增加了维护的复杂度。不过，到了数据量千万级别或者以上的时候，我们会发现，它们都是值得的。 二、 MySQL数据库多台服务搭建 1台MySQL机器，实际上是高风险的单点，因为如果它挂了，我们Web服务就不可用了。而且，随着Web系统访问量继续增加，终于有一天，我们发现1台MySQL服务器无法支撑下去，我们开始需要使用更多的MySQL机器。当引入多台MySQL机器的时候，很多新的问题又将产生。 1. 建立MySQL主从，从库作为备份 这种做法纯粹为了解决“单点故障”的问题，在主库出故障的时候，切换到从库。不过，这种做法实际上有点浪费资源，因为从库实际上被闲着了。 2. MySQL读写分离，主库写，从库读。 两台数据库做读写分离，主库负责写入类的操作，从库负责读的操作。并且，如果主库发生故障，仍然不影响读的操作，同时也可以将全部读写都临时切换到从库中（需要注意流量，可能会因为流量过大，把从库也拖垮）。 3. 主主互备。 两台MySQL之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了“单点故障”问题。任何一台故障，都还有另外一套可供使用的服务。 不过，这种方案，只能用在两台机器的场景。如果业务拓展还是很快的话，可以选择将业务分离，建立多个主主互备。 三、 MySQL数据库机器之间的数据同步 每当我们解决一个问题，新的问题必然诞生在旧的解决方案上。当我们有多台MySQL，在业务高峰期，很可能出现两个库之间的数据有延迟的场景。并且，网络和机器负载等，也会影响数据同步的延迟。我们曾经遇到过，在日访问量接近1亿的特殊场景下，出现，从库数据需要很多天才能同步追上主库的数据。这种场景下，从库基本失去效用了。 于是，解决同步问题，就是我们下一步需要关注的点。 1. MySQL自带多线程同步 MySQL5.6开始支持主库和从库数据同步，走多线程。但是，限制也是比较明显的，只能以库为单位。MySQL数据同步是通过binlog日志，主库写入到binlog日志的操作，是具有顺序的，尤其当SQL操作中含有对于表结构的修改等操作，对于后续的SQL语句操作是有影响的。因此，从库同步数据，必须走单进程。 2. 自己实现解析binlog，多线程写入。 以数据库的表为单位，解析binlog多张表同时做数据同步。这样做的话，的确能够加快数据同步的效率，但是，如果表和表之间存在结构关系或者数据依赖的话，则同样存在写入顺序的问题。这种方式，可用于一些比较稳定并且相对独立的数据表。 国内一线互联网公司，大部分都是通过这种方式，来加快数据同步效率。还有更为激进的做法，是直接解析binlog，忽略以表为单位，直接写入。但是这种做法，实现复杂，使用范围就更受到限制，只能用于一些场景特殊的数据库中（没有表结构变更，表和表之间没有数据依赖等特殊表）。 四、 在Web服务器和数据库之间建立缓存 实际上，解决大访问量的问题，不能仅仅着眼于数据库层面。根据“二八定律”，80%的请求只关注在20%的热点数据上。因此，我们应该建立Web服务器和数据库之间的缓存机制。这种机制，可以用磁盘作为缓存，也可以用内存缓存的方式。通过它们，将大部分的热点数据查询，阻挡在数据库之前。 1. 页面静态化 用户访问网站的某个页面，页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次，是通过动态CGI查询数据库获取之外，之后都直接将本地磁盘文件返回给用户。 在Web系统规模比较小的时候，这种做法看似完美。但是，一旦Web系统规模变大，例如当我有100台的Web服务器的时候。那样这些磁盘文件，将会有100份，这个是资源浪费，也不好维护。这个时候有人会想，可以集中一台服务器存起来，呵呵，不如看看下面一种缓存方式吧，它就是这样做的。 2. 单台内存缓存 通过页面静态化的例子中，我们可以知道将“缓存”搭建在Web机器本机是不好维护的，会带来更多问题（实际上，通过PHP的apc拓展，可通过Key/value操作Web服务器的本机内存）。因此，我们选择搭建的内存缓存服务，也必须是一个独立的服务。 内存缓存的选择，主要有redis/memcache。从性能上说，两者差别不大，从功能丰富程度上说，Redis更胜一筹。 3. 内存缓存集群 当我们搭建单台内存缓存完毕，我们又会面临单点故障的问题，因此，我们必须将它变成一个集群。简单的做法，是给他增加一个slave作为备份机器。但是，如果请求量真的很多，我们发现cache命中率不高，需要更多的机器内存呢？因此，我们更建议将它配置成一个集群。例如，类似redis cluster。 Redis cluster集群内的Redis互为多组主从，同时每个节点都可以接受请求，在拓展集群的时候比较方便。客户端可以向任意一个节点发送请求，如果是它的“负责”的内容，则直接返回内容。否则，查找实际负责Redis节点，然后将地址告知客户端，客户端重新请求。 对于使用缓存服务的客户端来说，这一切是透明的。 内存缓存服务在切换的时候，是有一定风险的。从A集群切换到B集群的过程中，必须保证B集群提前做好“预热”（B集群的内存中的热点数据，应该尽量与A集群相同，否则，切换的一瞬间大量请求内容，在B集群的内存缓存中查找不到，流量直接冲击后端的数据库服务，很可能导致数据库宕机）。 4. 减少数据库“写” 上面的机制，都实现减少数据库的“读”的操作，但是，写的操作也是一个大的压力。写的操作，虽然无法减少，但是可以通过合并请求，来起到减轻压力的效果。这个时候，我们就需要在内存缓存集群和数据库集群之间，建立一个修改同步机制。 先将修改请求生效在cache中，让外界查询显示正常，然后将这些sql修改放入到一个队列中存储起来，队列满或者每隔一段时间，合并为一个请求到数据库中更新数据库。 除了上述通过改变系统架构的方式提升写的性能外，MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许，从硬件层面解决问题，可以选择老一点的RAID（Redundant Arrays of independent Disks，磁盘列阵）或者比较新的SSD（Solid State Drives，固态硬盘）。 5. NoSQL存储 不管数据库的读还是写，当流量再进一步上涨，终会达到“人力有穷时”的场景。继续加机器的成本比较高，并且不一定可以真正解决问题的时候。这个时候，部分核心数据，就可以考虑使用NoSQL的数据库。NoSQL存储，大部分都是采用key-value的方式，这里比较推荐使用上面介绍过Redis，Redis本身是一个内存cache，同时也可以当做一个存储来使用，让它直接将数据落地到磁盘。 这样的话，我们就将数据库中某些被频繁读写的数据，分离出来，放在我们新搭建的Redis存储集群中，又进一步减轻原来MySQL数据库的压力，同时因为Redis本身是个内存级别的Cache，读写的性能都会大幅度提升。 国内一线互联网公司，架构上采用的解决方案很多是类似于上述方案，不过，使用的cache服务却不一定是Redis，他们会有更丰富的其他选择，甚至根据自身业务特点开发出自己的NoSQL服务。 6. 空节点查询问题 当我们搭建完前面所说的全部服务，认为Web系统已经很强的时候。我们还是那句话，新的问题还是会来的。空节点查询，是指那些数据库中根本不存在的数据请求。例如，我请求查询一个不存在人员信息，系统会从各级缓存逐级查找，最后查到到数据库本身，然后才得出查找不到的结论，返回给前端。因为各级cache对它无效，这个请求是非常消耗系统资源的，而如果大量的空节点查询，是可以冲击到系统服务的。 在我曾经的工作经历中，曾深受其害。因此，为了维护Web系统的稳定性，设计适当的空节点过滤机制，非常有必要。 我们当时采用的方式，就是设计一张简单的记录映射表。将存在的记录存储起来，放入到一台内存cache中，这样的话，如果还有空节点查询，则在缓存这一层就被阻挡了。   异地部署（地理分布式） 完成了上述架构建设之后，我们的系统是否就已经足够强大了呢？答案当然是否定的哈，优化是无极限的。Web系统虽然表面上看，似乎比较强大了，但是给予用户的体验却不一定是最好的。因为东北的同学，访问深圳的一个网站服务，他还是会感到一些网络距离上的慢。这个时候，我们就需要做异地部署，让Web系统离用户更近。 一、 核心集中与节点分散 有玩过大型网游的同学都会知道，网游是有很多个区的，一般都是按照地域来分，例如广东专区，北京专区。如果一个在广东的玩家，去北京专区玩，那么他会感觉明显比在广东专区卡。实际上，这些大区的名称就已经说明了，它的服务器所在地，所以，广东的玩家去连接地处北京的服务器，网络当然会比较慢。 当一个系统和服务足够大的时候，就必须开始考虑异地部署的问题了。让你的服务，尽可能离用户更近。我们前面已经提到了Web的静态资源，可以存放在CDN上，然后通过DNS/GSLB的方式，让静态资源的分散“全国各地”。但是，CDN只解决的静态资源的问题，没有解决后端庞大的系统服务还只集中在某个固定城市的问题。 这个时候，异地部署就开始了。异地部署一般遵循：核心集中，节点分散。 核心集中：实际部署过程中，总有一部分的数据和服务存在不可部署多套，或者部署多套成本巨大。而对于这些服务和数据，就仍然维持一套，而部署地点选择一个地域比较中心的地方，通过网络内部专线来和各个节点通讯。 节点分散：将一些服务部署为多套，分布在各个城市节点，让用户请求尽可能选择近的节点访问服务。 例如，我们选择在上海部署为核心节点，北京，深圳，武汉，上海为分散节点（上海自己本身也是一个分散节点）。我们的服务架构如图： 需要补充一下的是，上图中上海节点和核心节点是同处于一个机房的，其他分散节点各自独立机房。 国内有很多大型网游，都是大致遵循上述架构。它们会把数据量不大的用户核心账号等放在核心节点，而大部分的网游数据，例如装备、任务等数据和服务放在地区节点里。当然，核心节点和地域节点之间，也有缓存机制。 二、 节点容灾和过载保护 节点容灾是指，某个节点如果发生故障时，我们需要建立一个机制去保证服务仍然可用。毫无疑问，这里比较常见的容灾方式，是切换到附近城市节点。假如系统的天津节点发生故障，那么我们就将网络流量切换到附近的北京节点上。考虑到负载均衡，可能需要同时将流量切换到附近的几个地域节点。另一方面，核心节点自身也是需要自己做好容灾和备份的，核心节点一旦故障，就会影响全国服务。 过载保护，指的是一个节点已经达到最大容量，无法继续接接受更多请求了，系统必须有一个保护的机制。一个服务已经满负载，还继续接受新的请求，结果很可能就是宕机，影响整个节点的服务，为了至少保障大部分用户的正常使用，过载保护是必要的。 解决过载保护，一般2个方向： 拒绝服务，检测到满负载之后，就不再接受新的连接请求。例如网游登入中的排队。 分流到其他节点。这种的话，系统实现更为复杂，又涉及到负载均衡的问题。 小结 Web系统会随着访问规模的增长，渐渐地从1台服务器可以满足需求，一直成长为“庞然大物”的大集群。而这个Web系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。 系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。