下载掌阅APP，畅读海量书库
立即打开
云服务面向的是多用户，对服务系统例如界面、功能、流程等存在较多的个性需求。在云服务设计上，通过对典型需求的分析，需要将这些部分设计为可配置，以满足不同的用户的需求。
传统应用和云服务都存在可配置的要求，但云服务对配置要求更为复杂，而且由于可靠性要求，在更改配置时，服务要不中断，能够立即生效。
为了适应云服务面向多用户的需求，一般将云服务配置分为系统级、客户级和用户级，客户级又称为站点（site）级，这些配置各有侧重点，对运行系统影响各有不同，下面一一进行讲解。
传统服务系统配置以客户应用功能为主，例如对界面、功能、流程等的不同需求，而在云服务设计时，系统配置一般以技术运营、部署参数为主，一般不会涉及功能性配置。这些配置以配置资源池的形式存在，可能存储在文件中，也可能存储在数据库中，设计时要考虑监控配置项的改变，保障配置改变能及时生效。我们以亚马逊的云服务平台为例，亚马逊提供的云服务主机产品是一种IaaS服务，用户可以方便地根据自己的需求选择不同CPU、内存、硬盘的主机能力，而支撑这些主机的网络资源，如主机名称、IP地址（无论内网IP还是外网IP）是以资源分配的形式下发到购买的服务中，不同的用户内网IP地址和主机名是可以相同的，由亚马逊的虚拟交换机和虚拟网关（其实都是一种软件组件）来进行隔离，这对用户是透明的（用户看不到，也无法配置虚拟交换组件）。这部分的工作完全由亚马逊的工作人员来完成，尽管用户可以通过某些配置界面来管理自己的“网络组”，但这实际上是在云服务供应商提供好的配置沙盒里面构建自己的空间。
用户对自己的服务的配置不会影响到其他人，但反过来，如果亚马逊修改了系统配置，那客户第一时间就会看到结果。比如亚马逊经常会主动推送一些操作系统级别的补丁和更新，在用户收到邮件或者短信通知时，往往系统已经自动升级完了，但是用户没有受到任何的运行影响。还有某些用户所在区域发生重大故障，云服务提供商甚至可以在毫无知觉的情况下将客户购买的云服务整体迁移至灾备系统，而所有的配置项（包括网卡、IP、路由、防火墙、域名解析等）全部没有发生变化。如果不使用系统配置和资源相互隔离等设计技术，是做不到这一点的。
云服务的站点是对特定客户服务的入口，一般站点配置相当于传统业务的业务配置，不同于传统模式，这些配置是不同客户使用不同配置，是系统运行中根据用户所属的客户服务动态调整的，因此，一般不再采用配置文件方式，而是使用数据库来记录配置，用户登录不同站点加载不同配置项。
站点配置包括功能、流程、界面等，在架构时，要考虑不同客户的需求变化，尽量使各个功能动态组合，根据配置来决定功能、流程和界面，以同时支持不同的客户需求。
下面以阿里云来说明站点配置。对于阿里云的管理后台来说，用户面对的是一个完全界面化的管理门户。用户可以增加、变更和删除管理员，为购买的基础服务设定安全组和安全策略，定制监控措施和观察数据报告，划分网络组，管理自己的DNS，做网站备案。阿里云的配置管理门户对用户来说就是一个可以管理配置的“站点”。用户在这个站点对每一个购买的服务功能都可以深度定制。从结构上来说，阿里云的配置后台是基于B/S结构的系统，每一个配置项都是存储到数据库中，再经由程序推送到相应的服务实例。
和系统配置由云服务商负责不同，在云服务中的站点配置大多是由客户挑选具备运维管理维护能力的人来实施的，虽然这项工作也可以委托给云服务提供商来完成（比如通过电话或者工单的方式），但是出于安全性和及时性的考虑，客户还是愿意自己来负担这部分的人力成本，自行实施。
需要说明的是，由于站点配置需要体现客户的经营特色，阿里云甚至对企业客户提供企业定制化界面和皮肤展示功能，让配置管理后台看起来像是企业自己的一个产品门户，这种深度定制化的功能也得到了广大企业级用户的青睐，具有品牌经营意识的用户愿意为此付费。
站点配置决定企业用户统一功能集、流程和界面中企业相关的商标等显式的需求变化，是企业用户对供应商的统一要求，而用户配置则是用户根据自己的习惯，在企业需求的基础上，设置应用功能、流程和自己的界面，以提升工作效率。
在设计用户配置时，首先要分析不同用户可能的习惯，将界面、功能和流程尽可能按照不同组合予以对比，排除不可能选择，按照剩余方式提取配置，提升系统适应性，以最大限度地满足用户需求。
现以PaaS平台供应商提供的数据存储能力产品为例。很多PaaS供应商都提供基于关系型数据库（MySQL、Oracle、PostgrelSQL等）、缓存（Redis）、分布式文件存储（ODS、DFS）等产品，这些存储产品都提供了各种细粒度的功能参数配置，诸如配置文件存储的实际位置、大小、分片机制、主备机制、监控模式、故障恢复机制等。用户需要针对自己具体的业务场景来精心调配。这些配置由于和具体技术实现相关，因此会由专业的DBA或运维人员负责。PaaS平台供应商如无客户的强烈要求，基本不会触碰这些配置，因为这些配置和用户的使用强相关。
可管理性是云服务的基本要求之一，云服务配置层次较多，配置复杂度很高，因此需要根据系统规模设立专门的配置服务器，对系统中的系统配置集中管理，可以查看、修改站点与用户配置，这是云服务系统不同于一般企业服务配置的需求。
云服务提供商基本是基于虚拟化来提供资源能力的，宿主机和虚拟主机的数量在每一个单独的数据中心都有上万台甚至几十万台，如果不采用集中化的配置管理，配置变更就会是一个工作量惊人的工作。从整备机器、装机、初始化操作系统配置到根据实际应用配置基础服务软件，需要一个能够集中存储配置信息并适时下发到自动管理的机制，这就是中央化配置管理系统所需实现的工作。以微博为例，微博的follow功能由上千台Redis服务器组成，每个Redis服务器都是一主多从关系，所有的Redis服务器按照业务逻辑分片来存储用户的个人关系。如何维护这数千台缓存服务的故障、升级、系统及应用配置，就需要云服务商提供一个良好的配置管理中心。特别是升级过程，其滚动式升级能让所有的配置以不间断的方式从更新的服务配置中心下拉，以保证不同版本的Redis服务能够正确协同服务。
还有一个例子就是配置管理中心能够有效地统一研发和生产环境配置的差异。很多情况下，研发环境和生产环境差异巨大（如IP地址和端口的不同），使用统一的配置中心后，在研发和生产环境可以使用统一的key，但是获取到不同的值，可以保证代码的一致性。例如同样获取一个远端的RMI服务实例，如果不使用统一的配置管理中心，就必须把配置的IP地址写死到文件中，如果上线时忘记修改，就会造成事故；如果使用云服务商提供的配置管理服务，将IP地址放到不同的配置中心，而使用相同名称的环境变量，这样上线时，就能获得不同的IP地址，保证不会出现因为疏忽而导致的错误。