GitChat · 架构 | 大规模私有云产品自动升级的架构选型和实战

GitChat 作者：冰尘
原文：大规模私有云产品自动升级的架构选型和实战
关注微信公众号：GitChat 技术杂谈，一本正经的讲技术

一、项目背景概述

对于云计算，每个人都有自己的定义，有按SAAS，PAAS，IAAS划分的；有按公有云，私有云和混合云划分的。但是不管是哪一种方式，都面临如何自动化运维成千上万甚至百万级别的机器的挑战。下面分享一个实际案例，其基本要求如下：

私有云，里面有上万台左右的机器，是一个在全球有着３～４千万用户的私有云平台。
由企业在自有的数据中心单独搭建，在把应用软件以及服务器整租给用户，除所有者之外的用户无法使用。
网络安全要求限制特别的严格，不能上外网，且不能远程直接登录产品的服务器
生产环境被隔离了２个大型的虚拟网络：管理虚拟网络和客户软件产品虚拟网络，同时，每个客户都有一个产品的虚拟网络，不同客户的产品虚拟网络直接不能直接访问。
网络访问是单向的，客户软件产品的虚拟网络里面的机器能访问管理虚拟网络里面的机器，反过来禁止访问，这个太恶心了。
私有云里面９０％以上的都是Ｗｉｎｄｏｗｓ操作系统，以后也还会继续使用Ｗｉｎｄｏｗｓ操作系统
能自动对企业维护的产品进行版本升级，其产品是一个混合了java，C++，.NET技术的Web应用，且能安装在WebSphere，JBoss，WebLogic应用服务器上，Web服务器支持Apache，IIS。
运维的软件产品，很多客户都是有很多集群的，比如１6台应用服务器，３台报表服务器等。
升级的时候要求，对于多台应用服务器，先升级一台，如果升级成功，在并行升级其他的服务器，就牵涉到跨服务器的依赖等待的问题
所有的用户名和密码，不能持久化存储到本地，且所有的密码都是通过一款专业的密码管理器软件专门管理的
不能买现有的收费的产品，因为预算有限
有的应用服务器和Web服务装在同一台机器上，有的装在不同的机器上。
维护升级的产品，除了A之外，以后还要扩展到B，C，D
支持Active Directory的配置，数据库备份等。
第三方软件的安装和升级

二、架构选型

从上面的要求来看，其实难度是非常的大的，而且刚接到这个项目的时候，就听说这个项目失败过3~4次。当时感觉压力特别的大。于是在项目选型的时候，考虑过项目成本的问题，只能从开源产品和自己定制两个方向入手：

Chef
Puppet
Ansible
Window PowerShell DSC
定制开发

那么究竟应该选择开源框架呢？还是自己从头定制呢？该何去何从？当时在进行调研需求的时候，因为感觉需求要求多，首先想到的就是定制开发，但是后面经过分析，其实自己定制开发的许多功能，市面上的一些开源软件已经实现，比如，要基于配置文件进行管理，在应用产品的服务器上能有一个引擎,能解析和执行定义的配置文件，并能保证任意执行很多次，只要配置文件不变，结果就不会有变化（幂等性原则）, 所以我们没有必要重复发明轮子，因为这是软件工程中最避讳的事情。于是便先研究看看是否有开源框架能满足需求，如果没有，我们在自己着手定制开发；至于买商业软件，费用太高，客户不会同意,因为成本会很高，比如Chef的企业版都是按安装的机器收费，而且还是每年交一次，收的还是美金，Word天啊，也太贵了吧。那么，至此，我们的思路只能往开源框架考虑，如果开源框架的某些功能满足不了我们的要求，我们就在其上增强它。下面是具体的选型的心路历程。

首先我们知道管理的服务器的规模较大，对于网络方面，我们只能用拉模式（Pull），而不能使用推模式（Push），为什么呢？

我们知道自动化配置管理工具的一般思路就是用户先定义一个配置文件（用JSON，YAML，XML或者其他文件格式），然后把需要达到的配置目的描述在这个配置文件里面，比如我要启动一个Tomcat的服务，我要关闭一个防火墙端口，然后客户端（目标节点），从某种途径得到这个配置，但是不管是何种方式，无外乎两种，别的管理服务其动推送给目标节点，让目标节点执行其预设的配置，另外一种方式就是，每隔一段时间，目标节点到指定的配置管理服务器上查询比较一下，看是否有要执行的配置文件，或者有更新配置文件，如果有,目标节点就下载下来执行，如果没有,目标节点就不管了，维持现有的配置状态，具体请看下图。

图1：推模式

图2：拉模式

如果是推模式的话，增加一台被管理的服务器，管理工作站就必须知道增加的一台的服务器的远程登录的用户名和密码，才能在远程的机器上主动推送配置信息并执行。另外还有一点也很重要，目标节点必须在任何时候都连着管理工作站，否则一旦有新的或者更新的配置需要的推送的时候，恰巧其不在线，推送就会失败。推送模式架构简单，而且不需要另外搭建一套配置管理服务器，只要当前的工作站能远程连接到目标机器就行，在小规模的应用中还不失为一种高效的方法，但是一旦被管理的目标节点规模逐渐增大的时候，就会显得捉襟见肘。而拉模式就很好的避免了这个问题，目标节点可以定时的去配置管理服务器上，查询是否有新的配置或者更新的配置需要拉取，如果有的话，就拉取，而不用实时的连接上服务器，另外还能把要在目标节点上执行的预期状态先按角色或者机器名称部署在配置管理服务器，有利于自动配置管理脚本的实施，唯一的缺点需要额外管理和搭建一台配置管理服务器，考虑我们需要管理几千台服务器，我们只能选择拉模式。

既然我能当前的项目只能有拉模式，而Ansible本身对拉模式也不支持，且Ansible对Window的系统支持的不是特别好，所以Ansible在当前的项目上就不用考虑了。

另外网络也是单向的，客户软件产品的虚拟网络里面的机器能访问管理虚拟网络里面的机器，反过来禁止访问。这样的话，如果用推模式的话，从网络上也行不通。

另外根据我们和客户的访谈，我们发现，私有云里面９０％以上的都是Ｗｉｎｄｏｗｓ操作系统，以后也还会继续使用Ｗｉｎｄｏｗｓ操作系统。这点很出乎我们的意料，在我的印象中，Window操作系统收费是非常高的，而且自动运维一般使用Linux或者Unix的居多，奇怪的是当前的私有云中竟然有这么多的Windows的机器。我们对Puppet，Chef以及Window PowerShell DSC过了一遍，发现Chef和Window PowerShell DSC对Windows操作系统的支持特别好，而且Chef还直接提供了菜谱（Receipt）对Window PowerShell 资源和Window PowerShell脚本的调用（先不着急，待会儿笔者会解释Windows PowerShell和Window DSC的关系和区别）。至此，我们基本上把Puppet排除掉了，因为Puppet虽然也支持Windows也不错，但是没有Chef做的更好（个人通过官方文档和网上资料获得的，如果读者恰巧是Puppet的粉丝党，不喜勿喷！！！）

那么最后剩下的开源可选框架，就只剩下了Chef和PowerShell DSC，通过对客户的进一步访谈，我们知道，客户的私有云的运维人员有很多是PowerShell的专家，而且他们现在也经常使用PowerShell脚本维护系统着系统的运维。但是考虑到，环境中还有一部分的非Windows机器，而PowerShell对非Window的机器支持的也不是特别的好。刚开始，我们还考虑用Chef来实现客户的需求，但是后面通过进一步的需求挖掘，我们发现客户这次需要我们升级的产品在私有云里面，为了维护的方便，使用的都是Windows操作系统，而且以后高层也希望继续使用Windows操作系统，PowerShell DSC本身就是微软的产品，其和Windows的兼容性和血缘关系更近，所以Window PowerShell DSC也是一个不错的选择。那么到底应该是哪个呢？

通过对Chef和Window PowerShell DSC的研究，我们发现，Chef其实设计还是挺复杂的，光是数据库就有6 数据库，9个角色，2个表空间，虽然非常的灵活和强大，但是还是非常的复杂。而PowerShell DSC的表的设计就非常的简单，PowerShell DSC 5.1 就3张表。

Device
StatusReport
RegistrationData

但是以后还会不会因为高层的变动或者以后私有云上面也会把产品部署在非Windows的机器上？不得而知，但是目前只用Windows系统部署其产品。没有一步到位的永恒架构，只有不断演化的架构。考虑到目前用户只是进行不同产品的小版本以及补丁包的自动化升级，而且用户中本身就有很多的PowerShell 的专家，所以架构选型就定为了PowerShell DSC。同时还需要考虑到以后如果万一PowerShell DSC不能满足要求的时候，如何以最低的成本，把已开发的PowerShell DSC的自定义的Resource 迁移到Chef。

三、项目实战落地

说干就干，首先要了解什么是PowerShell DSC, PowerShell DSC的能满足管理上万台私有云机器的任务吗？当现有的PowerShell的资源模块满足不了我们的特别升级要求的时候，如何做定制和扩展？如果以后万一PowerShell DSC满足不了架构要求的时候，PowerShell DSC如何能够与Chef进行无缝的集成？PowerShell DSC的服务器支持负载均衡吗？
下面的章节，请耐心听笔者一一道来，但是为了照顾没有PowerShell DSC相关知识背景的读者，笔者会先对PowerShell DSC进行扫盲。

3.1 PowerShell DSC 简介

说到PowerShell DSC，先说一下 PowerShell， PowerShell其实就是类似于Linux系统的Bash, csh，ksh，其已经快速成长为Mircosoft Windows的和VMWare生态系统的标准自动化工具，微软投入了巨资，使得PowerShell能够管理Microsoft Windows Servers和Microsoft的应用程序。那么什么是PowerShell DSC呢？

PowerShell DSC是PowerShell的一部分，是一个新的管理平台,英文全称为，PowerShell Desired Status Configuration,翻译成中文就是理想管理配置状态。PowerShell DSC 能够为系统和软件服务部署和管理配置数据，并且允许定义当前机器的状态从而确保机器的状态和你预定义的没有偏差。

那么什么是状态的呢？状态指的就是一台机器上面的所有东西，比如，OS和软件的所有配置设置，任何文件和进程需要被设置成什么内容。DSC能够保证帮助我们处理所有的配置数据并且能重复执行且每次重复执行结果都一样。WindowPowerShell DSC能够帮助我们用户的资源在数据中心被正确的配置；DSC是PowerShell语言的扩展，为数据中心的资源提供了可申明，可自动化，满足幂等（可重复执行）性和一致性的配置能力。DSC能够帮助专业运维人员，开发，IT基础设施管理员等定义目标节点的配置（计算机或者设备）同时阻止配置的不一致性和配置状态的漂移。

说白了就是，PowerShell DSC是基于声明式的语言，运维者只需要提出自己需要对目标配置要求，而不需要具体关注这个目标是如何实现的，举个简单的栗子，比如说我们想要在目标机器上安装一个Chrome浏览器，我们只需要做如下的声明。

用户使用的时候，只需要声明一下，需要在目标节点上安装什么语言的Chrome浏览器，安装文件的路径在什么地方，其就会自动在目标机器上安装，且只安装一次，如果上面已经安装了，就会跳过；另外如果对DSC进行配置应用并监控（ApplyAndMonitor）模式的话，如果有人不小心，删除了Chrome浏览器，则DSC的引擎每隔一个固定的周期（比如30分钟）就会监测到，并自动把删除的浏览器补装上去，从而防止声明状态的漂移，而我们用户所做的事情，就是声明一下我要装一个浏览器，并声明引用了那个开源模块的DSC资源（xChrome模块是开源的）并传入两个辅助参数，而且还可以指定在那些机器上执行。是不是感觉很强大啊！！！

那么PowerShell到底和PowerShell DSC是什么关系呢？悄悄的告诉大家：

PowerShell DSC是PowerShell的一部分，而PowerShell是WMF（Window Management FrameWork）的一部分。没有独立的PowerShell DSC的安装包，也没有独立的PowerShell安装包，PowerShell和PowerShell DSC都包含在Window Management Framework的安装包里的。当前的最新版本是5.1，大家可以到下面的网站去下载

3.2 PowerShell DSC 关键术语

其实真的很难在一篇文章中把所有的DSC的事情都介绍清楚，所以在介绍DSC的架构风格之前，先简单介绍一下DSC的核心概念：

幂等性（Idempotent）

一个操作被执行多次，结果都是一样的
DSC配置文件（DSC Configuration File）

一个PowerShell脚本文件，包含了DSC的领域描述语言（Domain Description Language）已经被执行的DSC资源（Resource）的列表。
DSC配置数据（DSC Configuration Data）

一个PowerShell的脚本文件或者一段代码，其定义了一批可以改变目标节点的数据。
DSC 资源（DSC Resource）

DSC资源就是一个PowerShell的模块，其包含了幂等性函数（需要实现Set-Target，Get-Target和Test-Target三个函数接口），通过执行这写具有幂等性的函数从而达到用户期望的配置
DSC cmdlets

其实就是 PowerShell的cmdlets，只不过专门用来操作DSC，比如Start-DSCConfiguration， Get-DSCResource等等，总结一下凡是带有DSC关键字的PowerShell的cmdlets一般都属于DSC的cmdlets，哈哈。
本地配置管理器（Local Configuration Management，简称LCM）

其实就是一个DSC的目标节点的执行引擎，控制着DSC配置文的执行已经把执行反馈执行结果。
MOF文件

其实就是一个机器可读的，于平台无关的一个文件，其定义了很多的规范，一般我们在开发DSC配置文件的时候，都是通过编辑DSC的配置文件生成MOF文件，然后MOF文件被目标节点的机器上的DSC的执行引擎执行。
漂移（Drift）

一个专业术语，主要用来描述并比较预期目标机器的状态和当前已经达到的配置状态的对比，看是否产生了偏移，比如我需要安装定义了我要在目标节点上安装.NET 4.5.2，如果目标机器上的的确确通过DSC安装了.NET 4.5.2，那么我们就可以认为当前的预期配置状态（Desired Configuration Status，DSC）没有漂移（Drift），否则就有漂移（Drift）。

3.3 PowerShell DSC 架构风格

正如上面所阐述一样，PowerShell DSC也支持两种架构模式，推模式和拉模式部署。

推（Push）模式的部署流程

从上图可知，当用推模式部署的时候，配置文件一般都是手工通过start-DscConfiguration DSC cmdlets推送到远程的目标节点上的。当MOF文件被LCM执行完后，会把执行结果反馈给用户推送MOF文件的控制台上面。

拉（Pull）模式的部署流程

从上图可知，当用拉模式部署的时候，通过DSC 配置文件生成的MOF文件就会部署到一个专门存放MOF文件的DSC的服务器上，目前执行HTTP Web服务器或者SMB服务器两种模式。一般一个目标节点就会对应一个MOF甚至多个MOF文件，目标节点必须实现注册到DSC的拉服务器上，才能定时的从DSC的拉服务器上拉取目标节点对应的MOF文件。拉取的时候，其会先检查MOF文件对应生成的checksum的文件，是否有变化，如果有变化，就说明MOF文件有变动，其就会向DSC的拉服务器请求最新的MOF文件，并执行，否则其不会重新下载一篇MOF文件，并保证的当前MOF文件定义的期望配置状态不会漂移。

我们当前的项目，因为需要的管理的服务比较多，所以需要采用拉模式方式的架构进行部署，具体原因请参考上面第2部分的产品选型分析的章节。

3.4 项目整体功能架构

为了提高的用户的操作的简单性，我们需要开发一个基于Web的管理系统，允许客户通过这个Web管理系统进行创建部署计划，查看执行情况。

但是目前DSC没有提供这样的管理界面，需要我们自己定制开发（Chef也开发了类似的管理界面，但是需要用其收费版，而且价格还不菲），所以我们决定开发一套自己的管理界面，考虑到ASP.NET里面有很多的现成的控件可以使用，而且开发效率也高，我们的团队里面也有很多的ASP.NET高手，我们决定用ASP.NET来实现前端的管理系统。当然，用J2EE也是完全可以的。

有上图可知，其分成了3大部分，

部署计划管理系统

部署计划系统是一个Web系统，其包含了下面的功能。

用户和角色管理，用户和角色管理，服务器管理，邮件通知，执行计划和状态管理，历史执行记录管理，日志和异常管理，集成管理，DSC 配置文件管理，系统设置管理，MOF文件管理等。
DSC拉服务器

MOF 文件上传，DSC MOF 文件和模块管理，原生的DSC报告管理，定制的DSC资源，定制的DSC报告管理。
1万多台的目标机器

目标机器会根据MOF定义的预期状态执行相应的任务，主要有下面的任务，服务器信息收集，部署前的校验，数据库备份，应用文件备份，部署执行，部署步骤跟踪，集群依赖处理，部署日志分析等等。

3.5 项目关键技术解决

用PowerShell DSC管理上万台机器，其实还是挺有难度的，有很多的难点技术需要攻克，因为当前市场上几乎没有任何的PowerShell DSC的中文书籍，而且PowerShell DSC本身是一个轻量级的DevOps框架，但是幸运的是，因为其原理和架构不是很复杂，所以我们能用很短的时间熟悉和摸透其基本的原理，从而大大的方便了我们的定制和扩展，下面请听笔者逐一给大家分享遇到的拦路虎。

3.5.1 如何搭建DSC拉服务器集群

不幸的是，DSC 拉服务器默认情况下是不支持建立DSC的拉服务器集群模式的。因为我们知道，PowerShell DSC的默认数据库为ESENT文件数据库；或者oleDB形式的Access数据库（数据库文件后缀名为：mdb）,而这两种数据库都是文件数据库，那么应该如何解决这个问题呢？后面通过研究，发现一种变通的方法，就是先把当前的Pull服务器的数据库改成Access，然后通过ODBC把Access映射到SQL Server上面，其原理图如下：

关于如何配置ODBC到SQL Server服务器，请参考我这篇文章。

把数据库切换到SQL已经做到了，那么应该如何搭建DSC的拉服务器集群呢？搭建集群当然少不了Ngnix。其架构图如下：

需要注意的是，这里面有两个需要注意的细节：

如何切换到Access数据库

默认安装方式下DSC拉服务器，如果用xDscWebService DSC资源安装Pull服务器的话，其默认方式是ESENT文件数据库的方式；那么如何把Pull服务器的存储数据库改成Access数据库呢？答案其实很简单，只需要修改MSFT_xDSCWebService.psm1文件。

具体步骤，请参考我的CSDN博客。
DSC 拉服务器的UUID注册key

两台DSC拉服务器的注册的UUID的Key必须是一样的，否则就做了负载均衡,下面是安装一台DSC拉服务的DSC的配置代码。

两台DSC服务器上的RegistrationKey必须要保持成同一个值，否则机器不能正常工作。

3.5.2 平滑切换成Chef管理

前面提到，如果未来万一用DSC满足不了用户的需求后，那么如何保证DSC前期的投入，包括定制的DSC资源，DSC的配置文件，能够完全复用到Chef上面来呢？经过研究，我们发现，Chef提供了完美的解决方案，那就是利用Chef的dsc_script 配方，可以直接包装PowerShell的配置文件。下面以用PowerShell DSC创建一个用户为例子，其Chef的配方的代码如下：

真是太完美了，我们担心的DSC定制资源复用的问题也完美解决了，也没有了后顾之忧，我们可以大胆放心的使用PowerShell DSC，即使以后架构切换成了Chef，我们也能大部分复用，从而节省客户的成本（根据笔者对客户的观察和经验，这种情况应该很少会发生，客户追求的是产品稳定，而不是新的技术）

3.5.3 解决多服务器的依赖

因为客户的环境里面有很多的集群，而在安装的时候，会遇到下面的类似的场景，比如，先在一台域控制服务器上安装域控（Active Directory），等域控制服务器A安装好后，在把另外一台机器B加入到域控服务器A中；还有一种常见的场景是，比如，先安装数据库服务器，然后在安装应用服务器；不管是何种情况都牵涉到了跨机器间的依赖；刚好，在DSC5.x中提供了一个DSC的资源专门做这个事情，这个资源就WaitForAll,WaitForAny以及WaitForSome。下面咱们先看一个简单的例子。

上面的Configuration文件会生成2个MOF文件：doTestAction.mof和doWaitForAction.mof文件。
其中让computerA在注册DSC Pull服务器的时候，注册doTestAction.mof，computerB注册doWaitForAction.mof文件。

不知道大家发现没有，在Node doWaitForAction的配置中，我们显式的依赖了computerA的backupFile的Resource，也就是说必须等ComputerA的backupFile的DSC的resource的状态返回True的时候，computerB的generateFile的DSC resource才会被执行。

好了，原理说完了，例子也说完了；但是不知道大家有没有想过，为什么computerB知道ComputerA的任务已经完成了呢？是ComputerB通过DSC Pull服务器不断查询DSC的Report服务器得到的结果吗？还是computerB直接调用ComputerA的某项服务器查询ComputerA的backupFile的DSC的resource的状态是否已经返回True了呢。

笔者通过抓包工具发现，其实是computerB直接调用ComputerA的某项服务器查询ComputerA的backupFile的DSC的resource的状态是否已经返回True。具体过程咱们来分析。

从上图可以看出，经过三次TCP/IP握手之后，computerB会给computer发送一个HTTP 的Post的请求。请求的URI为wsman，端口的5985。

那么到底发送了什么消息呢？其实就是通过5985或者5986端口，定时不停的发送WSMan Web服务的状态查询，其HTTP头（HTTP体内容有点多，省略了）如下，

POST /wsman HTTP/1.1

Connection: Keep-Alive

Content-Type: application/soap+xml;charset=UTF-8

User-Agent: Microsoft WinRM Client

Content-Length: 1614

Host: computerA:5985

如果一旦被依赖的服务器的DSC资源被DSC引擎执行完成并成功后，其就会得到一个成功的状态信号，从而在被依赖的服务器的任务执行成功后，其继续执行，否则如果其依赖的服务器的任务失败了，则当前的服务器就会停止执行当前的任务。

值得一提的是，这种方案，需要一个前提，就是被等待的服务器一定要开通支持WINRM服务的5985或者5986端口，且WINRM服务器是启动的，否则当前方法就会受阻；替代的方案就是自己开发一套解决依赖的方法，比如，通过report服务器来管理和查询被依赖服务器的状态，从而决定当前的机器上的DSC的任务十分继续执行。

3.5.4 DSC资源的定制

虽然DSC在Github上提供了很多的第三方的开源的DSC资源供我们使用。但是肯定还有一些地方不能满足我们的要求，必须我们要分析安装的日志，然后把安装日志里面的特殊错误分析并抓取出来，这个时候，默认提供的DSC资源就满足不了我们的要求了，我们必须要自己定制DSC资源，那么应该如何定制呢？其实DSC给我们提供了很好的定制方法。

既可以通过写.NET程序来实现，也能通过写PowerShell脚本来实现。笔者就以写PowerShell脚本为例子，简单介绍一下如何定制一个DSC资源，大家看了之后，自己可以依葫芦画瓢，把自己的业务逻辑代码填充进去。注意，笔者本机的开发环境是PowerShell DSC 5.1。

第1步：安装xDSCResourceDesigner

我们知道DSC的resource的格式要求比较复杂，不但要定义MOF文件，还要定义MOF Schema，同时还要声明PowerShell的module。工欲善其事，必先利器。那么，有好的工具去屏蔽其复杂性，能够自动生成呢？有的，就是xDSCResourceDesigner。首先通过下面的命令来进行安装。

PS C:\Users\rodney> Install-Module -Name xDSCResourceDesigner

安装之后，我们允许Get-Command -Module xDSCResourceDesigner下面的命令，我们就能看到起提供的函数。

第2步：利用 xDSCResourceDesigner 提供的函数（New-xDscResourceProperty）生成定制的DSC资源的模板

生成的文件如下：

第3步：依次打开下面的三个文件

并进行修改，比如，

修改SayResource.psm1文件，在 Set-TargetResource函数中加上一行 Write-Verbose $msg。
在 Test-TargetResource函数中加上一行返回值 $false。

第4步：测试SayResource DSC resource，编写一个测试的configuration文件，名字为Test.ps1

运行Test.ps1，则可以看到SayHello的DSC resource已经生效。

其实定制过程也蛮简单的，就是实现Test-TargetResource，Set-TargetResource和Get-TargetResource三个方法，并按DSC的资源的规定，做一些申明和DSC资源描述就行了。

四、总结

唠唠叨叨给大家分享了一个实际的项目的架构选型，功能架构以及难点问题攻关，但是其实PowerShell DSC本身的内容还是挺多的，即使写一本书也不为过，如果大家想对DSC有进一步的学习和了解，请参考我的CSDN博客：http://blog.csdn.net/column/details/14191.html。这里面有一个专栏，专门针对PowerShell DSC。

其实架构是不断演化出来的，受很多因素的影响，环境，客户的技术偏好和技术积累，项目的预算，开发人员的技能水平和技能栈，总之，没有一统天下，永恒不变的架构，只有适合项目需求，客户需要的，恰到好处的架构就是好架构。这就好比当时淘宝从开始买了一套商业的电子商务软件然后在上面做二次开发，到请SUN公司的技术专家帮助迁移到J2EE，在到自己重新改造，自有架构，架构是动态演化的。

在当前的环境，当前的项目下，我们使用了 PowerShell DSC 完全满足了我们的项目需要，但是如果换了一家公司，可能就会用别的架构，但是其选型考虑的因素和思路的方法还是有规律可遵循的。任何架构都有考虑不周的地方，或者有不足的地方，如果读者发现了，或者有更好的想法和建议，还请不吝多多批评指教。

最后，非常感谢大家，耐心的看完了笔者的文章，哪怕能帮助到读者启发和拓展一下自己的思路，鄙人也会感到莫大的欣慰，希望以后能有机会和大家一起共事，夜深了，熬了几天夜写出的文章，终于出炉了，最后祝大家身体舒适，心情舒悦。

实录：《冰尘：大规模私有云的架构选型和实战解析》

彩蛋

重磅 Chat 分享：《如何在三年内快速成长为一名技术专家》

分享人：
方腾飞并发编程网创始人，支付宝架构师

Chat简介：

工作前三年是职业生涯中成长最快的几年，在这段时间里你会充满激情，做事专注，也容易养成良好的习惯。

在我们公司有些同学在前三年中就快速成为某一个领域的技术专家，有些同学也可能止步不前。本场Chat和大家一起探讨下如何在三年内快速成长为一名技术专家。

学习方法：

掌握良好的学习心态掌握系统化的学习方法

知识如何内化成能力

广度和深度的选择

实战技巧：

你需要学会的编码习惯如何在普通项目中提高自己的能力

在业务团队做

引用文字

开发如何成长

想要免费参与本场 Chat ？

很简单，公众号后台回复「技术专家」