ORACLE EBS 系统主数据管理
四、客户（Customer）
（一）客户数据管理概述
（二）EBS 交易社区架构（TCA）
（三）客户的配置文件分类（Profile Class）
（四）客户的创建规则
（五）客户的多组织控制（MOAC）
（六）客户的交易方层属性及交易方关系
（七）客户的账户层与地点层属性
（八）客户账户层的“分类”分组属性
（九）客户账户层的“市场营销”分组属性
（十）客户账户层的“关系”分组属性
（十一）客户账户地点层的“特性”分组属性
（十二）客户账户与地点层的“通信”分组属性
（十三）客户账户与地点层的“联系人”分组属性
（十四）客户账户与地点层的“联系人：职责”分组属性
（十五）客户账户与地点层的“银行账户”分组属性
（十六）客户账户与地点层的“付款方法”分组属性
（十七）客户账户与地点层的“配置文件：事务处理”分组属性
（十八）客户账户与地点层的“配置文件：单据打印”分组属性
（十九）客户账户与地点层的“配置文件：金额”分组属性
（二十）客户账户的“地址地点与业务目的”属性
（二十一）R12客户的账户层与地点层属性
（二十二）客户数据的合并
（二十三）客户数据的其它管理功能
五、结语
三、客户（Customer）
客户是企业提供产品与服务的对象，是企业的衣食父母，是企业存在的前提条件。在当今世界经济全球化、一体化，市场竞争日益充分、激烈的大背景下，如何满足客户需求，为客户提供周到、细致的服务，是企业经营管理活动的头等大事。因此，在企业信息化实践方面，相较于最近几年才逐渐得到更多重视的供应商关系管理系统SRM，企业的客户关系管理系统CRM的发展历史渊源要早得多，产品的发展现状也丰富、完善得多。习惯上，人们很早就已经将CRM
与传统的ERP看作是属于前后台（Front-Office、Back-Office）范畴，可以相提并论，具有一定独立性的两大产品。
任何企业在市场环境中总是同时扮演着“供应商与客户”两种角色，作为“客户”角色，要管理好自己的“供应商”，这属于SRM产品的范畴；作为“供应商”，要对自己的“客户”进行有效管理，这属于CRM产品的范畴。无论属于哪种角色，都存在着所谓“供应商与客户”的竞争关系，但是在市场竞争的环境中，作为“供应商的客户”与作为“客户的供应商”两者所处的竞争地位与竞争优势是截然不同的，存在着明显的强弱差距。这一差距反映到企业管理实践与SRM/CRM产品的系统设计上，也会表现出鲜明的特点。
在企业管理实践中，企业对于供应商的管理，通常会采取“严进宽出”的总体策略，管理的重点放在供应商的“准入”资格认证过程管理，以及使用中的绩效考核管理上。而企业对于客户的管理，则通常会采取“宽进严出”的总体策略，管理的重点放在客户的信息收集与挖掘管理，以及使用中的风险控制管理上。企业管理实践这一根本性的策略差别，使得系统在供应商与客户的主数据管理的内容方面差别较大，客户主数据管理的复杂性与灵活性要求要明显高于供应商主数据。推而广之，使用供应商主数据的业务模块如PO系统，使用客户主数据的业务模块如OM系统，其复杂性也会有很大不同。有经验数据表明，PO与OM在系统实施上的相对困难程度比较是120：170。
（一）客户数据管理概述
尽管对于一个确定的企业来说，其所具有的客户范畴可能并不复杂，例如有些生产专业仪器设备的企业，其客户面可能很窄，客户数量也很有限，但作为一个通用的、需要适应各行各业需要的CRM/ERP产品，其客户主数据所要考虑的因素，其所必须具有的灵活性与适应性就异常复杂了。有些企业的客户可能是政府机关、公用事业单位、生产制造企业、服务业、分销商、零售商、个人消费者等等，情况千差万别。若从信息系统设计与管理的角度去考察，客户主数据需要重点考虑以下几种情况：
一是“潜在客户”与“当前客户”。我们通常所说的“客户”（Customer）实际上是个广义的概念，它包括了两种情况，一种即所谓“售前客户”（Prospect），还未达成销售，企业正针对其展开营销活动（Marketing），或者正在向其提供报
价，等待最终结果；一种是所谓“当前客户”（Account），已经与之达成过交易，正在继续为之提供产品或服务，希望未来能达成更多销售。
二是“集团客户”（Headquarter）与“子公司客户”（Subsidiary）。有些企业采取的集中采购的管理策略，由总部统一执行采购下单，但由各下述企业收货付款，或者由总部统一议定采购条款、签订框架合作协议，但由下属各企业执行具体采购过程。系统必须考虑这些企业之间的复杂关系，考虑销售策略、价格与条款政策、信用风险管控活动等等在它们之间如何协调问题。
三是“组织客户”与“个人客户”。有些企业产品或服务的对象，既可能是组织或单位，也可能个人，需要进行差别化的管理；
四是“直销”与“分销”。有些企业的产品由销售部门直接卖给终端客户（组织或个人），但有些则可能需要通过“中间商或渠道伙伴”（一级代理、二级代理等）才能最终到达最终用户手上；
五是“集中销售”与“分散销售”。有些企业的产品线可能比较复杂，不同产品可能由不同的销售团队，执行不同的销售政策销售给同一个客户，企业必须考虑相互间如何协调等问题。
六是“客商关系”。即有些企业的客户可能同时还是企业的供应商，存在互为买卖的关系，客观上需要在买卖政策、款项结算等方面做特殊考虑。
总之，外部客户的复杂性（个人与组织、组织与组织间关系）、销售过程的复杂性（售前、售中、售后）、企业内部的复杂性（不同产品、不同销售团队、不同销售地域）等等因素的综合作用，要求企业的客户主数据管理必须满足不同业务模块（诸如Marketing、Sales、Quote、Contract、i-Store等等）的不同功能使用的具体要求。
（二）EBS 交易社区架构（TCA）
早期的ERP产品对于供应商与客户主数据的管理要求相对比较简单，主要是满足PO/AP模块、OM/AR模块等核心业务系统的要求。随着企业信息系统集成从核心业务系统向外围支持系统如SRM/CRM的扩展，以及企业管理的数据信息逐步由过去单个企业的“分散”应用向未来企业集团化、全球化的“集中统一”过渡，系统对于客户及供应商的主数据管理在完善性、灵活性、可扩展性等方面提出了更高的要求。正是在这一需求的大背景之下，ORACLE于
2000年提出了有关主数据管理（当时主要是针对客户）的所谓“交易社区架构（Trading Community Architeture，TCA）”的概念。
所谓交易社区架构TCA的概念，主要包含两层涵义，一层是从“技术架构”角度的主数据如何共享去讲的，系统中的各业务模块被看作是“社区成员”，相互之间使用统一的主数据，系统只需集中维护单一的数据来源。有关这一层涵义，今天人们已经很熟悉，无需多讲；二层涵义是从“业务应用”角度的主数据如何“模型化”角度去讲的，正如前文已经提到，任何企业在市场环境中，都同时承担着既是供应商又是客户的双重角色，作为每一独立存在的企业个体，在系统中也仿佛组成了一个“社区”，“社区成员”相互之间有时也存在着复杂的交易连接关系。以下重点介绍ORACLE客户数据“业务应用”层面的TCA 架构模型化问题。
既然每一个企业作为“商业实体”是一种客观存在，那么其在系统中首先也可以被看作是一个具有身份标识、独立存在的“交易方”（Party），该“交易方”可以是组织，也可以是个人，拥有自己的、不依赖于其他方的数据信息，如组织、人员、产品、物理地址等等。在未与这些“交易方”产生真实的买卖活动之前，或曰“售前”阶段，这些“交易方”同样属于广义的“客户”概念范畴（Prospect），需要在系统中对它们相关的市场活动进行有效管理。
一旦与交易方（Party）达成买卖协议或开始下单，则可能需要与交易方达成一种或多种“买卖关系”，对于每一种“买卖关系”，EBS系统将之称为“账户（Account）”，注意，不要将这里的账户Account与所谓的“银行账号Bank Account”相混淆；在每一个账户Account之下，为了进一步区分某些交易属性（例如收单地点、银行账号等），可以再分为多个“账户地点”（Account Site）；一个“交易方”与“账户”的组合（Party+Account）称之为“客户Customer”（而不是Prospect）。我们通常所说的“客户经理”，其英译“Account Manager”，正是很好地体现了这里的所谓“交易方账户”的概念。
在EBS系统中所谓的“客户间关系”，主要是指“交易方关系”而言的，由于交易方Party是独立的存在，Party之间所建立的关系也是一种客观存在，不依赖于与己方所建立的某种买卖关系（Account），故而，这种“交易方关系”可以适应于所有业务系统（而不仅仅是传统的OM/AR系统）的使用需要。
早期的EBS版本（以及很多其它品牌的ERP产品）在实际应用中，人们都习惯于以“供应商地点、客户地点”来表达“总公司与子公司”的关系或层次结构，但基于EBS的TCA架构，对于客户的“层次结构”关系，ORACLE强烈建议不要使用“客户地点”来表达，因为相关CRM模块的诸多应用（例如“商机管理”等）是建立在Party而不是Site之上的。对于一个总公司附带若干分公司、子公司的客户情形，只要客观上需要将某一个分、子公司在市场营销、客户管理方面重点对待，ORACLE的建议倾向于为之建立单独的“Party”实体（细粒度管理），而不是降格为Site。
关于TCA的一个账户Account可以有多个“账户地点Account Site”的问题，其含义类似于原来的“一个供应商或客户可以有多个地点Site”。而一个交易方Party 具有多个账户Account的问题，主要是为了满足己方（而不是交易方或客户）内部业务管理复杂性的需要，例如公司有性质迥异的两种不同产品（如电视机和X光机），有不同的销售团队、商务策略以及生产厂家，但可能具有同一个客户（交易方），为了在内部管理上加以区分，则可以在一个Party之下建立多个Account。这有点类似你去同一个银行的不同支行开了多个户头，银行（一般是分行级）的业务管理系统第一次会根据你的身份证信息建立一个统一的“客户号”（类似Party Number），以后你在任一支行所开的户头均属于此客户号之下的Account。
按照ORACLE在多年以前的有关设想，最终包括供应商数据在内，所有有关客户的系统应用都要逐步迁移并适应于TCA架构。但遗憾的是，近十年时间过去，或许不可见的“技术架构”层面的TCA工作早已完成，但可见的、业务应用层面的TCA工作的进展还是比较缓慢：供应商主数据的TCA似乎尚未启动，客户主数据的TCA才开了一个头，核心业务系统如OM/AR的改造尚有很长的路要走，目前还无法实现“Party”层与“Account”层的数据分离，还无法实现按“Party”（或Account）实现业务数据与活动的“卷积”（Roll-Up）。
甚至于用“交易方Party+账户Account”这个概念取代传统的“Cunstomer”概念都有一定困难。原先在R11后期版本中出现的Party术语，在R12版本中甚至被改回用Customer术语代替，原先的Party Number则被改称为Registry ID。在系统中创建Party（Customer）的同时，必须同时为之创建Account，Party
或Customer与Account被捆在了一起（原先的设想是根据需要再创建Account）。看来，ORACLE的主数据TCA架构适应性改造还任重道远，是一项艰巨的长期任务。
尽管TCA架构的目前使用尚不完善，使用范围有限，但在下面有关客户主数据的具体介绍中，将会不时出现它的身影，故为了帮助理解有关内容，这里有必要对其概念与内涵作简要介绍。
（三）客户的配置文件分类（Profile Class）
尽管在R11中，“客户配置文件分类”的设置并非为创建客户数据的前提条件，但在R12中，由于被改成了必须的前提条件，故这里要首先对之作介绍。所谓“客户配置文件分类”，简单说就是对具有相似信誉、业务量和付款周期（以及滞纳费用制度）的客户（账户Account）进行分组。对于每个配置文件分类，可以定义诸如信用限额、付款条件、对帐单周期、开票和折扣信息之类的信息。也可以为经营业务所用的每种币种定义财务费用、催款和对帐单限额等等信息。如下图82所示：
作为业务实例，可以定义三种“客户配置文件分类”：一种为准时付款客户，他们具有良好的信用限额；一种为延迟付款客户，他们具有较高的财务费用利率；另一种为经常准时付款的客户，可以通过提供折扣来鼓励他们提前付款。
定义的“客户配置文件分类”被客户（Account）所引用后，则该客户就具有了配置文件中所定义的所有相关属性。对于已经定义的配置文件相关字段进行修改，在保存时系统会询问对于已经引用该配置文件的客户的相关字段如何处理，如下图83所示：
具体包括：“不更新现有配置文件”，即配置文件分类的更改只对新增客户数据有效；“更新所有配置文件”，即配置文件分类的更改对包括已存在的所有客户数据有效；“更新所有未自定义的配置文件”，即只更新与当前被更改值具有相同值的客户数据。显然，系统的这种控制方式，对于批量定义、维护客户数据的某些字段内容将十分方便、灵活。
R12与R11的客户配置文件相比，内容及Tab页分组有一定变化，如下图84所示：
总的来说，客户配置文件的字段属性主要是应用于AR系统中（个别与OM系统有关，如信用检查等），为AR系统相关字段提供默认值或控制有关业务行为。“客户配置文件分类”因为只作用于客户的Account层或Account Site层（被引用），故称之为“账户配置文件”可能更合适。有关客户配置文件字段详情，请参考ORACLE相关文档，这里不赘述。
（四）客户的创建规则
目前，无论是R11还是R12，当在其中创建新客户（Customer）时，系统均需要同时创建一个账户Account及其账户地点Site。R11与R12的共同之处是，Acount与Site均可由系统自动生成（或手工输入）的编号Number作为唯一性标识，Site必须具有真实的物理地址Address；R11与R12的不同之处在于，R11的账户名Account Name变成了R12的账户说明Account Description，R12的Account Site还可以为之给定一个地点名Site Name。系统同时还会给客户自动创建（或手工输入）一个“顶层”的唯一性编号Number，在R11中称为交易
方编号Party Number，在R12中称为注册号Registry ID。
在R12中创建新客户时，首先需确定客户类型是“组织”还是“个人”，然后在“账户信息”区域选择账户类型是“外部”还是“内部”。“内部”表示公司内部客户的账户，“外部”表示公司外部客户账户。必须为账户赋予一个账户地点的物理地址，并同时为该“账户地点”指定其所属的业务实体OU，及其业务目的（收单方、收货方等等）。如下图85所示：
系统会为新创建的客户自动生成（或手工输入）注册标识号（亦即Party Number）、客户账户号（Account Number）以及账户地点编号（Account Site Number）。然后可以根据业务需要，为该客户添加新的账户Account（及其Site，所属的OU以及业务目的等），也可以为当前账户Account 添加新的地点Site信息。如下图86所示：
R11的新客户及其所属账户的创建过程略为抽象，在输入新客户名称后，系统如果未发现有重名，则会弹出是否“新建”的询问界面，如下图87所示：
在新建客户名及其账户、账户地址后，系统会自动为之生成两行记录，一行是交易方编号和地址信息，一行是该交易方所属账户编号（Account）及其地点编号（Site）。如要为该交易方添加新的账户Account，需要定位到“交易方编号和地址信息”行，再按“确定”方可。如要为已经存在的账户编号（Account）新增地点Site，必须先定位到“账户编号（Account）及其地点编号（Site）”行，再按“确定”
方可。如下图88所示：
与供应商名称必须唯一不同，新建的客户名称（Party Name）并不要求唯一，可以重复。已经存在的客户名称也可以更改。与供应商只包含一个编号不同，每个客户数据至少包含“交易方编号Party Number”、“地点编号Site Number”、“账户编号Account Number”以及“业务目的地点编号Usage Location Number”（多个，具体下面介绍）等等。这些编号是自动生成还是手工输入，取决于如下设置：Party Number与Site Number分别由系统配置文件“HZ：自动生成交易方编号、HZ：自动生成交易方地点编号”控制，Account Number与Usage Location Number 则分别由AR系统选项的“自动客户（账户）编号”与“自动地点编号”来控制。
ORACLE EBS 系统主数据管理
四、客户（Customer）
（五）客户的多组织控制（MOAC）
（六）客户的交易方层属性及交易方关系
（七）客户的账户层与地点层属性
（八）客户账户层的“分类”分组属性
（九）客户账户层的“市场营销”分组属性
（十）客户账户层的“关系”分组属性
（十一）客户账户地点层的“特性”分组属性
（十二）客户账户与地点层的“通信”分组属性
（十三）客户账户与地点层的“联系人”分组属性
（十四）客户账户与地点层的“联系人：职责”分组属性
（十五）客户账户与地点层的“银行账户”分组属性
（十六）客户账户与地点层的“付款方法”分组属性
（十七）客户账户与地点层的“配置文件：事务处理”分组属性
（十八）客户账户与地点层的“配置文件：单据打印”分组属性
（十九）客户账户与地点层的“配置文件：金额”分组属性
（二十）客户账户的“地址地点与业务目的”属性
（二十一）R12客户的账户层与地点层属性
（二十二）客户数据的合并
（二十三）客户数据的其它管理功能
五、结语
（五）客户的多组织控制（MOAC）
与供应商的多组织控制是在供应商Site层完全相同的是，客户数据的多组织（OU）控制也是在账户地点层Account Site进行的。R11的客户数据新建“交易方Party”及其账户Account信息虽然是在确定的OU下进行的，但实际它们都是跨OU的，但与之同时创建的Account Site 则是属于确定的OU的。如要为不同的OU创建同一Party下的不同Account Site，必须首先切换到目标OU 下方可。而R12因为在创建Account与Account Site的同时需要为之分配相应的OU，故其操作要方便、灵活得多。
（六）客户的交易方层属性及交易方关系
R12的Party层具有更多可默认作用于下一层的结构化信息，R11的Party 层信息则相对比较简单。R11与R12两者均具有查询客户“第三方数据”的功能，如D&B企业数据查询。D&B企业数据就是前面在讲物料分类编码UNSPSC 时，提到的邓百氏咨询公司（Dun & Bradstreet）所提供的一项企业基础数据服
务。凡在该公司登记注册并接受其认证的企业，均会得到一个全球唯一的9位企业代码标识，称为DUNS编号。其它企业可以向该公司购买并与之在线联网自动更新自己感兴趣的交易方（供应商或客户）的基础信息资料。如下图89所示R12客户Party层信息：
R11与R12均可以在Party层维护交易方关系，R12的维护操作更方便一些。结合前面有关TCA架构的简要介绍，在对上述客户Party层、Account层、Site层的相互关系有了更多理解之后，我们或许对于ORACLE强调，不能用传统的“客户+客户地点”的方式来表达客户的组织层级关系，有了更进一步的认识。
（七）客户的账户层与地点层属性概述
EBS的客户账户层属性与地点（地址）层属性的关系和供应商层与供应商地点层属性的关系类似。R11客户账户层属性共有13个Tab页，包括“地址、分类、订单管理、市场营销、通信、联系人、联系人：职责、银行账户、付款方法、配置文件：事务处理、配置文件：单据打印、配置文件：金额、关系”，而账户地点层属性则也有13个Tab页，包括：业务员目的、特性、通信、联系人、联系人：职责、银行账户、付款方法、配置文件：事务处理、配置文件：单据打印、配置文件：金额，以及对应于每个“业务目的地点层”的“详细资料、账户、订单管理”。抛开账户层的“地址”与地点层的“业务目的”两个有特殊关系的Tab页不论，只属于账户层的Tab属性页只有“分类、市场营销、关系”，只属于地点层的Tab页只有“特性”以及“业务目的地点”的“详细资料、账户”。
（八）客户账户层的“分类”分组属性
“分类”属性只在客户账户层出现，主要是有关客户账户自然属性（分类等）销售关系、税等方面的内容。如下图90所示：
上图“分类”Tab页中，“配置文件分类”不可输入，只是显示“配置文件：事务处理”Tab页的相关字段设定值，并随之而变化；分类（Classfication）、类别（Category）的LOV均是可以根据需要在Lookup Code中预先定义的；类型（Type）包括“内部、外部”选项；在多组织环境下，由于只能在账户地点而非账户层分配税码，故“税码”字段只能是“Location”；在多组织环境下，“销售人员”也只能在账户地点定义，故此字段留空；仅当税收方法为V AT（增值税），且“AR系统选项”窗口中的“允许改写”选项设置为“是”时，才需要（也只有）在这里的“税”与“税额舍入”字段输入值，不可以在地点层相关字段输入，并且Accont层输入值优先于“AR系统选项”层的输入值；“参考”字段是系统内部的客户账户唯一性标识（内码ID），可以手工输入，也可以由系统自动生成（使用“客户接口”批量导入时，系统也会自动产生），一旦保存后就不可更改。
（九）客户账户层的“市场营销”分组属性
“市场营销”属性只在客户账户层出现，主要是提供一些该客户账户有关财务数据的简单说明，如下图91所示：
其中的“收入”区域，使用“本年度”和“下一年度”字段来估计此客户账户在本年度和下一年度的潜在收入；其余主要表示其所属会计年度的相关设置值。
（十）客户账户层的“关系”分组属性
客户账户层的“关系”不同于交易方的关系，交易方层的关系仅代表客户的独立的自然属性，如组织层次结构关系等，而客户账户层的关系只是基于当前与己方所具有“买卖关系”而产生的派生关系，如“代为收单、收货或互惠（关联）”等，图中的关系“类型”字段仅供参考，其LOV值可以在Lookup Code中定义。客户账户“关系”属性只
在账户层出现。如下图92所示：
十一）客户账户地点层的“特性”分组属性
“特性”属性只在客户账户地点层出现，只是用来对客户账户地点提供某
些说明信息。如下图93所示：
其中的“译名”（Translation ，“折算”翻译不恰当）自动表示使用其它语言输入的客户名称，可用来替换外部文档的客户名称，此字段可与“语言”字段一起使用。“参考”字段系统内部的客户账户地点唯一性标识（内码ID），可以手工输入，也可以由系统自动生成（使用“客户接口”批量导入时，系统也会自动产生），一旦保存后就不可更改。“Geo改写”及“城市内部限制”字段，仅在使用第三方税务软件Vertex Quantum（美国）时才用得到。
（十二）客户账户与地点层的“通信”分组属性
账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供电
话、传真、电子邮件等信息。如下图94所示：
云计算平台设计参考架构 在私有云当中，主要包含以下几个组件：物理基础架构、虚拟化层、服务自动化层、服务门户、安全体系、云API和可集成的其它功能。（如图私有云参考架构） 图3.4 私有云参考架构 a) 物理基础架构 物理架构的定义是组成私有云的各种计算资源，包括存储、计算服务器、网络，无论是云还是传统的数据中心，都必须基于一定的物理架构才能运行。
在私有云参考架构中的物理基础架构其表现形式应当是以资源池模式出现，也就是说，所有的物理基础架构应当是统一被管，且任一设备可以看成是无状态，或者说并不与其它的资源，或者是上层应用存在紧耦合关系，可以被私有云根据最终用户的需求，和预先定制好的策略，对其进行改变。 b) 虚拟化层 虚拟化是实现私有云的前提条件，通过虚拟化的方式，可以让计算资源运行超过以前更多的负载，提升资源利用率。虚拟化让应用和物理设备之间采用松耦合部署，物理资源状态的变更不影响到虚拟化的逻辑计算资源。且可以根据物力基础资源变化而动态调整，提升整体的灵活性。 c) 服务自动化层 服务自动化层实现了对计算资源操作的自动化处理。它可以集中的监控目前整体计算资源的状态，比如性能、可用性、故障、事件汇总等等，并通过预先定义的自动化工作流进行
相关的处理。 服务自动化层是计算资源与云计算服务门户相关联的重要部件，服务自动化层拥有自动化配置和部署功能，可以进行服务模板的制定，并将服务内容和选择方式在云计算服务门户上注册，用户可以通过服务门户上的服务目录来选择相应的计算资源请求，由服务自动化层实现服务交付。 d) 云API 云应用开发接口提供了一组方法，让云服务门户和不同的服务自动化层进行联系，通过云API，可以在一个私有云当中接入多个不同地方的计算资源池，包括不同架构的计算资源，并通过各自的服务自动化体系去进行服务交互。 e) 云服务门户 云服务门户是用户使用私有云计算资源的接口，云服务门户上提供了所有可用服务的目录，并提供了完善的服务申请流程，用户可以执行申请、变更、退回等计算资源使用服务。
一、业务挑战 无锡华夏计算机技术有限公司于2000年1月成立，是无锡软件出口外包骨干企业。公司主要以面向日本的软件外包开发为中心，致力于不断开拓国内市场、为客户提供优质的系统集成等业务。随着企业的发展，IT投入不断加大，随之而来的PC管理问题也越来越突出。 华夏目前PC总拥有数1000台，主要用于研发和测试，由于项目多、任务紧，一台PC经常要用于不同的项目开发，而每次更换都要对PC系统进行重新安装和环境搭建。根据实际统计，华夏一个员工平均每年参与4个项目的开发，也就是每年要重新搭建四次开发环境，对测试人员来说这个数量还要更多；平均每次更换环境花费时间10个小时，华夏每年大约花费4万小时用于PC系统和环境搭建，按照人均工资15元/小时，每年花费在60万左右。 除此之外，由于PC的使用寿命较短，更新升级频繁，大量的PC就意味着每年都要有很多PC需要淘汰和更新，现在这个数字大约是10台/月，而随着华夏的发展壮大，这个数字会进一步增加，这就意味着华夏每年花在PC升级和更新的费用最少在50~60万。与此同时，大量的PC也是的企业的能源消耗巨大，电力花费居高不下；按照平均180W/台，一台PC工作8小时/天，工业用电0.9元/度，华夏每年的电费就将近15万元。 与巨大的IT投入相对应的就是IT资源利用率较低，PC分布在企业各个项目小组的开发人员手中，很难进行统一的管理调度，也无从得知PC的使用情况。软件开发的各个阶段对IT的需求都是不同的，我们无法得知某个正在进行的项目使用的PC资源是否有多余，无法将项目完成用不到的PC资源及时收回，以便给下一个项目小组使用，造成大量的IT资源浪费。
云计算资源池平台架构设计
目录 第1章云平台总体架构设计 (4) 第2章资源池总体设计 (5) 2.1 X86计算资源池设计 (6) 2.1.1 计算资源池设计 (6) 2.1.2 资源池主机容量规划设计 (8) 2.1.3 高可用保障 (9) 2.1.4 性能状态监控 (12) 2.2 PowerVM计算资源池设计 (14) 2.2.1 IBM Power小型机虚拟化技术介绍 (14) 2.2.2 H3Cloud云平台支持Power小型机虚拟化 (16) 2.2.3 示例 (18) 2.3物理服务器计算资源池设计 (19) 2.4网络资源池设计 (20) 2.4.1 网络虚拟化 (20) 2.4.2 网络功能虚拟化 (34) 2.4.3 安全虚拟化 (36) 2.5存储资源池设计 (37) 2.5.1 分布式存储技术方案 (37) 2.6资源安全设计 (46) 2.6.1安全体系 (46) 2.6.2 架构安全 (47) 2.6.3 云安全 (52) 2.6.4 安全管理 (59)
2.6.5 防病毒 (62)
第1章云平台总体架构设计 基于当前IT基础架构的现状，未来云平台架构必将朝着开放、融合的方向演进，因此，云平台建议采用开放架构的产品。目前，越来越多的云服务提供商开始引入Openstack，并投入大量的人力研发自己的openstack版本，如VMware、华三等，各厂商基于Openstack架构的云平台其逻辑架构都基本相同，具体参考如下： 图2-1：云平台逻辑架构图 从上面的云平台的逻辑架构图中可以看出，云平台大概分为三层，即物理资源池、虚拟抽象层、云服务层。 1、物理资源层 物理层包括运行云所需的云数据中心机房运行环境，以及计算、存储、网络、安全等设备。 2、虚拟抽象层 资源抽象与控制层通过虚拟化技术，负责对底层硬件资源进行抽象，对底层硬件故障进行屏蔽，统一调度计算、存储、网络、安全资源池。 3、云服务层 云服务层是通过云平台Portal提供IAAS服务的逻辑层，用户可以按需申请
容器云平台监控架构设计及优化
目录 1. 概述 (1) 2. 价值和意义 (1) 3. 监控方案选型 (1) 3.1 容器云监控方案有哪些 (1) 3.2 方案对比并确定 (3) 4. 基于prometheus的容器云平台监控架构设计 (4) 4.1 prometheus介绍 (4) 4.2 架构设计 (5) 4.3 监控点有哪些 (7) 4.4 重要组件介绍 (10) 4.5 数据可视化 (14) 4.6 高可用设计 (16) 4.7 性能优化与容量预估 (22)
1 概述 随着容器化的大力发展，容器云平台已经基本由Kubernetes作为统一的容器管理方案。当我们使用Kubernetes进行容器化管理时，传统监控工具如Zabbix无法对Kubernetes做到统一有效的全面监控，全面监控Kubernetes也就成为我们需要探索的问题。使用容器云监控，旨在全面监控Kubernetes集群、节点、服务、实例的统计数据，验证集群是否正常运行并创建相应告警。本章旨在于介绍容器云平台监控的架构设计及优化。 2 价值和意义 监控是运维体系中是非常重要的组成部分，通过监控可以实时掌握系统运行状态，对故障提前预警，以及历史状态的回放，还可以通过监控数据为系统的容量规划提供辅助决策，为系统性能优化提供真实的用户行为和体验。为容器云提供良好的监控环境是保证容器服务的高可靠性、高可用性和高性能的重要部分，通过对本章的学习，能够快速认识当前容器环境下都有哪些监控方案，并对主流的监控方案有一个系统的了解和认识。 3 监控方案选型 3.1 容器云监控方案有哪些 （1）Zabbix Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。 Zabbix核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。Server主要负责接
1.云计算参考架构 在私有云当中，主要包含以下几个组件：物理基础架构、虚拟化层、服务自动化层、服务门户、安全体系、云API和可集成的其它功能。（如图私有云参考架构） 图3.4 私有云参考架构 a) 物理基础架构 物理架构的定义是组成私有云的各种计算资源，包括存储、计算服务器、网络，无论是云还是传统的数据中心，都必须基于一定的物理架构才能运行。 在私有云参考架构中的物理基础架构其表现形式应当是以资源池模式出现，也就是说，所有的物理基础架构应当是统一被管，且任一设备可以看成是无状态，或者说并不与其它的资源，或者是上层应用存在紧耦合关系，可以被私有云根据最终用户的需求，和预先定制好的策略，对其进行改变。 b) 虚拟化层 虚拟化是实现私有云的前提条件，通过虚拟化的方式，可以让计算资源运行超过以前更
多的负载，提升资源利用率。虚拟化让应用和物理设备之间采用松耦合部署，物理资源状态的变更不影响到虚拟化的逻辑计算资源。且可以根据物力基础资源变化而动态调整，提升整体的灵活性。 c) 服务自动化层 服务自动化层实现了对计算资源操作的自动化处理。它可以集中的监控目前整体计算资源的状态，比如性能、可用性、故障、事件汇总等等，并通过预先定义的自动化工作流进行相关的处理。 服务自动化层是计算资源与云计算服务门户相关联的重要部件，服务自动化层拥有自动化配置和部署功能，可以进行服务模板的制定，并将服务内容和选择方式在云计算服务门户上注册，用户可以通过服务门户上的服务目录来选择相应的计算资源请求，由服务自动化层实现服务交付。 d) 云API 云应用开发接口提供了一组方法，让云服务门户和不同的服务自动化层进行联系，通过云API，可以在一个私有云当中接入多个不同地方的计算资源池，包括不同架构的计算资源，并通过各自的服务自动化体系去进行服务交互。 e) 云服务门户 云服务门户是用户使用私有云计算资源的接口，云服务门户上提供了所有可用服务的目录，并提供了完善的服务申请流程，用户可以执行申请、变更、退回等计算资源使用服务。 云服务门户收到最终用户的请求时，将根据预先定义好的策略对该请求进行立刻供应、预留或者排队。 不同的用户通过同一个云服务门户当中，将会看到只属于自己的应用、计算资源和服务目录，这是云计算当中的多租户技术，用户使用的资源在后台集中，但是在前端是完全的逻
本项目主要帮助读者掌握搭建OpenStack 云计算平台的环境设计及系统准备，包括硬件基本需求，OpenStack 云计算平台的搭建所需的软件包，部署一个实际的OpenStack 云计算平台拓扑结构，并在这个环境下进行系统安装基础工作。 掌握构建云计算平台的系统拓扑结构。 掌握系统拓扑结构下的网络配置。 掌握正确搭建云计算平台的安装基础工作。 云计算平台的系统架构 小李基本掌握了云计算平台搭建的基础知识，接下来需要对公司的应用需求进行调研，在此基础上要进行公司云计算平台的系统环境设计和系统搭建的基础安装工作，为此，小李当前要完成的任务如下。 公司云平台应用的需求分析。 公司云平台系统环境架构设计。 1.项目需求分析 （1）基本概念 需求分析是指理解用户需求，就用户的功能需求与客户达成一致，并需要估计项目风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户是处在主导地位的，需求分析工程师和项目经理要负责整理用户需求，为之后的项目设计打下基础。 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理等一系列需求工程。狭义上理解：需求分析指需求的分析、定义过程。 需求分析阶段结束后应该得到相应的需求分析报告。 （2）分析内容 学习目标 项目 环境设计和系统准备 二
OpenStack云计算基础架构平台技术与应用 22 需要分析的内容可以包含：公司应用需求、技术资金投入与生产效益、行业技术发展 趋势，国家政策支持等。 （3）分析过程 需求分析阶段的工作，可以分为4个方面：问题识别、分析与综合、制订规格说明、评审。 （4）分析方法 需求分析的方法有很多。如原型化方法、结构化方法和动态分析法等。 2．系统架构设计 一个项目的系统架构设计一般是由系统架构设计师来负责完成的。对于系统架构设计师来说，其主要职责有如下4条。 （1）确认需求 在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。 （2）系统分解 依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。 （3）技术选型 通过对系统的一系列的分解，架构师最终形成项目的整体架构。技术选择主要取决于项目架构。 架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会对项目预算、人力资源和时间进度等实际情况进行权衡，最终进行确认。 （4）制定技术规格说明 在项目开发过程中，架构师是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照他的架构意图去实现各项功能。 架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。 3．环境说明 ①若教学环境有足够的可供学生使用的服务器，则每组分配2台服务器进行练习。 ②若教学环境没有服务器，可使用PC代替，每组分配2台PC进行练习（每台PC 支持CPU虚拟化，双网卡，最低4GB内存，最低100GB硬盘）。
最全的云计算平台设计方案-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
1.云计算参考架构 在私有云当中，主要包含以下几个组件：物理基础架构、虚拟化层、服务自动化层、服务门户、安全体系、云API和可集成的其它功能。（如图私有云参考架构） 图私有云参考架构 a) 物理基础架构 物理架构的定义是组成私有云的各种计算资源，包括存储、计算服务器、网络，无论是云还是传统的数据中心，都必须基于一定的物理架构才能运行。 在私有云参考架构中的物理基础架构其表现形式应当是以资源池模式出现，也就是说，所有的物理基础架构应当是统一被管，且任一设备可以看成是无状态，或者说并不与其它的资源，或者是上层应用存在紧耦合关系，可以被私有云根据最终用户的需求，和预先定制好的策略，对其进行改变。 b) 虚拟化层 虚拟化是实现私有云的前提条件，通过虚拟化的方式，可以让计算资源运行超过以前更多的负载，提升资源利用率。虚拟化让应用和物理设备之间采用松耦合部署，物理资源状态的变更不影响到虚拟化的逻辑计算资源。且可以根据物力基础资源变化而动态调整，提升整体的灵活性。 c) 服务自动化层
服务自动化层实现了对计算资源操作的自动化处理。它可以集中的监控目前整体计算资源的状态，比如性能、可用性、故障、事件汇总等等，并通过预先定义的自动化工作流进行相关的处理。 服务自动化层是计算资源与云计算服务门户相关联的重要部件，服务自动化层拥有自动化配置和部署功能，可以进行服务模板的制定，并将服务内容和选择方式在云计算服务门户上注册，用户可以通过服务门户上的服务目录来选择相应的计算资源请求，由服务自动化层实现服务交付。 d) 云API 云应用开发接口提供了一组方法，让云服务门户和不同的服务自动化层进行联系，通过云API，可以在一个私有云当中接入多个不同地方的计算资源池，包括不同架构的计算资源，并通过各自的服务自动化体系去进行服务交互。 e) 云服务门户 云服务门户是用户使用私有云计算资源的接口，云服务门户上提供了所有可用服务的目录，并提供了完善的服务申请流程，用户可以执行申请、变更、退回等计算资源使用服务。 云服务门户收到最终用户的请求时，将根据预先定义好的策略对该请求进行立刻供应、预留或者排队。 不同的用户通过同一个云服务门户当中，将会看到只属于自己的应用、计算资源和服务目录，这是云计算当中的多租户技术，用户使用的资源在后台集中，但是在前端是完全的逻辑分离，有众多的安全保护措施来确保隔离。 f) 安全体系 在私有云当中，具有完整的安全体系，包括物理资源、虚拟化平台、系统安全、应用安全和用户访问安全，每个层次都有相关的安全监控和控制，确保最终用户的应用运行稳定可靠。 g) 集成 私有云当中可以集成其它更多的功能，以达到更好的服务效果。如服务级别管理，提供更好的服务质量。容量管理，为私有云的服务能力和扩展趋势作出建议。计量和收费，真正实现按使用付费。 虚拟化数据中心参考架构
2021年 云计算平台系统建设项目 设计方案
1.1设计方案 1.1.1平台架构设计 **高新区云计算平台将服务器等关键设备按照需要实现的功能划分为两个层面，分别对应业务层和计算平台层。 业务层中，功能区域的划分一般都是根据安全和管理需求进行划分，各个部门可能有所不同，云数据中心中一般有公共信息服务区(DMZ区)、运行管理区、等保二级业务区、等保三级业务区、开发测试区等功能区域，实际划分可以根据业务情况进行调整，总的原则是在满足安全的前提下尽量统一管理。 计算平台层中分为计算服务区和存储服务区，其中计算服务区为三层架构。计算服务区部署主要考虑三层架构，即表现层、应用层和数据层，同时考虑物理和虚拟部署。存储服务区主要分为IPSAN、FCSAN、NAS 和虚拟化存储。 云计算平台中计算和存储支持的功能分区如下图所示：
图云计算平台整体架构 图平台分层架构
基础架构即服务：包括硬件基础实施层、虚拟化&资源池化层、资源调度与管理自动化层。 硬件基础实施层：包括主机、存储、网络及其他硬件在内的硬件设备，他们是实现云服务的最基础资源。 虚拟化&资源池化层：通过虚拟化技术进行整合，形成一个对外提供资源的池化管理（包括内存池、服务器池、存储池等），同时通过云管理平台，对外提供运行环境等基础服务。 资源调度层：在对资源（物理资源和虚拟资源）进行有效监控管理的基础上，通过对服务模型的抽取，提供弹性计算、负载均衡、动态迁移、按需供给和自动化部署等功能，是提供云服务的关键所在。 平台即服务：主要在IaaS基础上提供统一的平台化系统软件支撑服务，包括统一身份认证服务、访问控制服务、工作量引擎服务、通用报表、决策支持等。这一层不同于传统方式的平台服务，这些平台服务也要满足云架构的部署方式，通过虚拟化、集群和负载均衡等技术提供云状态服务，可以根据需要随时定制功能及相应的扩展。 软件即服务：对外提供终端服务，可以分为基础服务和专业服务。基础服务提供统一门户、公共认证、统一通讯等，专业服务主要指各种业务应用。通过应用部署模式底层的稍微变化，都可以在云计算架构下实现灵活的扩展和管理。 按需服务是SaaS应用的核心理念，可以满足不同用户的个性化需求，如通过负载均衡满足大并发量用户服务访问等。 信息安全管理体系，针对云计算平台建设以高性能高可靠的网络安
云平台建设方案简介 2015年11月
目录 1. 云平台总体设计 1.1 总体设计方案 1.1.1 设计原则 1.1.2 支撑平台技术架构设计 1.1.3 支撑平台网络拓扑设计 1.1.4 通过云操作系统实现云计算中心运营管理 1.1.5 层次清晰的云计算中心部署架构设计 1.2 项目技术路线 1.2.1 X86系统架构 1.2.2 资源池化 1.2.3 弹性扩展 1.2.4 智能化云管理 1.2.5 充分考虑利旧 1.3 云项目建设成功案例 1.3.1 中国银联离线交易数据处理云平台 1.3.2 新疆公安云 1.3.3 国家中医药数据中心云平台
云平台总体设计 总体设计方案 设计原则 ?先进性 云中心的建设采用业界主流的云计算理念，广泛采用虚拟化、分布式存储、分布式计算等先进技术与应用模式，并与银行具体业务相结合，确保先进技术与模式应用的有效与适用。 ?可扩展性 云中心的计算、存储、网络等基础资源需要根据业务应用工作负荷的需求进行伸缩。在系统进行容量扩展时，只需增加相应数量的硬件设备，并在其上部署、配置相应的资源调度管理软件和业务应用软件，即可实现系统扩展。 ?成熟性 云中心建设，要考虑采用成熟各种技术手段，实现各种功能，保证云计算中心的良好运行，满足业务需要。 ?开放性与兼容性 云平台采用开放性架构体系，能够兼容业界通用的设备及主流的操作系统、虚拟化软件、应用程序，从而使得云平台大大降低开发、运营、维护等成本。 ?可靠性 云平台需提供可靠的计算、存储、网络等资源。系统需要在硬件、网络、软件等方面考虑适当冗余，避免单点故障，保证云平台的可靠运行。 ?安全性 云平台根据业务需求与多个网络分别连接，必须防范网络入侵攻击、病毒感染；同时，云平台资源共享给不同的系统使用，必须保证它们之间不会发生数据泄漏。因此，云平台应该在各个层面进行完善的安全防护，确保信息的安全和私密性。 ?多业务性 云平台在最初的规划设计中，充分考虑了需要支撑多用户、多业务的特征，保证基础资源在不同的应用和用户间根据需求自动动态调度的同时，使得不同的业务能够彼此隔离，保证多种业务的同时良好运行。 ?自主可控 云平台建设在产品选型中，优先选择自主可控的软硬件产品，一方面保证整个云计算中心的安全，另一方面也能够促进本地信息化产业链的发展。 支撑平台技术架构设计 图支撑平台技术架构 支撑平台总体技术架构设计如上，整个架构从下往上包括云计算基础设施层、云计算平台资源层、云计算业务数据层、云计算管理层和云计算服务层。其中： ?云计算基础设施层：主要包括云计算中心的物理机房环境； ?云计算平台资源层：在云计算中心安全的物理环境基础上，采用虚拟化、分布式存储等云计算 技术，实现服务器、网络、存储的虚拟化，构建计算资源池、存储资源池和网络资源池，实现 基础设施即服务。