![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
开发针对云优化的账单组件的目的是提供用于生成使用量账单的接口。云账单流程使用一套预定义的账单策略根据资源使用量数据生成账单。根据云计算策略不同，账单可以表示需要支付的真实金额，也可以是更抽象的交易表示法 — 这无所谓，因为这个账单服务没有规定必须使用某种经济模型。
本文简要讨论如何定义为面向服务的体系架构环境设计的云账单服务模块。它能够满足报价服务、转换函数和策略、支付方法和用户识别等功能性需求。它还能够满足安全性、可伸缩性、标准和容错等基本的非功能性需求。
首先，介绍这个云账单模块的架构。然后，我将解释账单策略背后的思想以及使用的语言和语法。还要讨论规则/推论引擎及其作用，最后讨论工作流和冲突解决战略。
通用的云账单服务模块应该提供端口类型以支持所有功能性需求（见下一节）：
- 账单服务根据从账单策略存储库获取的策略生成账单。
- 账单存储在账单存储库中，供经理使用。
图 1 显示会计和账单服务的基本架构。
图 1. 模块的架构
账单生成流程并不是自动的，需要由经理启动。服务的所有功能在一个 web 服务中实现。
图 2 显示模块的技术视图，展示各个子组件和这些不同技术之间的交互。
图 2. 模块的技术视图
这个账单服务通过一个 PHP 接口连接 web 服务器，从使用量记录 (UR) 存储库获取记录文档。
账单策略的简单示例如下：
- 1 CPU/h（使用小时数）等于 1 个代币
- CPU/h 大于 20h 时优惠 20%
无论账单策略是简单还是复杂，资源经理有时候希望修改它们。提前考虑到所有情况是不可能的，每次添加新策略时都修改源代码当然也是不可行的。
一定要明确区分账单逻辑和账单策略，账单逻辑计算最终的账单，而账单策略指定如何生成账单。账单策略并不是账单服务的组成部分；它们是账单服务使用的外部元素。它们由资源经理编写并存储在一个存储库中。账单服务使用这个存储库提取必需的策略以生成最终的账单。
假设希望把前面提到的两个策略示例形式化。可以这样表示：cpu_h(x) 是 x 个 CPU 小时，token(x) 是 x 个代币，那么：
(1)# bill = token(cpu_h(x));
(2)# if
cpu_h(x) > 20
then
bill = bill*.8;
|
这种表示法能够表达这两个策略；但是，它有两个主要问题：
- 它不是自然语言。
- 它无法表达所有情况。
请记住，设置账单策略的人不一定是程序员，让他们编写这样的表示法可能很困难。使用比这种表示法更自然的语言表达账单策略要容易得多。
第二个问题是使用这种表示法表达许多复杂的策略非常困难。业务规则可能会非常快地变动，账单规则必须相应地改变。只能使用健壮的规则语法满足未来策略的需求。
还有两种语言可以用来描述策略；它们各有优缺点。
自然语言允许用一般的英语表达策略，比如：
When the event is VM Assignment and the client's type is Platinum, then the cost per second is 0.0002 euros.
自然语言容易使用，便于掌握。这一点对于非技术用户最有吸引力。
还可以用领域特定语言（DSL）（使用规范文档中使用的语法和语义）描述上面的策略，如下所示：
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (seconds), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (Euros, Pounds, etc.)
与自然语言相比，领域特定语言（DSL）更具有结构化，更容易快速编辑和修改。
系统中的规则/推论引擎根据系统状态或用户输入演算规则。光有策略语法是不够的：还需要通过一种机制判断策略的有效性并演算策略。这就是设计规则引擎的目的。
这里介绍的引擎是一个使用增强的 Rete 算法实现的前向链规则引擎。在这个开发阶段，我的同事和我评估了几种规则引擎，其中两种引起了我们的注意：
- IBM 的 ACEL (Autonomic Computing Expression Language) 最初是作为 Autonomic Computing Policy Language 的组成部分开发的，用来描述策略什么时候应该应用于管理的系统。
- 如果要想使用行业标准，就必须使用 Java™ Rule Engine API (JSR94) 作为编程接口。
通过一个简单的 web 前端输入和修改账单规则。看一下规则/推论引擎的结构。
图 3. 规则/推论引擎
根据生产规则匹配新的或现有的事实称为模式匹配。规则引擎可以使用多种算法执行模式匹配。规则存储在生产内存中，推论引擎匹配的事实存储在工作内存中。
在修改或取消事实的地方，把事实插入工作内存中。如果系统有大量规则和事实，可能导致许多规则对于同一事实断言都是真的；这些规则是冲突的。使用冲突解决战略管理这些冲突的规则的执行次序。
在这里，工作流是指演算规则时的规则优先次序（应该先演算哪个规则？）冲突解决是指，如果多个规则的演算结果都是真，那么应该触发哪个规则。这两者都很重要，在成功的账单服务模块中必须实现它们。
接下来，简要讨论功能性需求。
现在，简要地介绍在云账单模块中要考虑的功能性需求。
云代理实例应该支持报价服务，让用户能够在使用资源之前查询报价。例如，“如果我在这个计算站点上运行某某东西，要花多少钱？” 报价不应该是固定的，应该只在短期内有效。
云代理实例必须实现一个转换函数，它根据基本的转换方案（比如一个 CPU 小时的费用等于一个代币）把使用量记录转换为代币数量，并根据经济模型和需求商定代币的实际货币价值。云代理实例应该允许资源所有者向它提供定制的转换模型，从而更好地为用户提供服务。
云代理实例必须能够识别出要为使用资源付费的实体。用户可能属于不同的虚拟组织并运行多个作业；在这种情况下，一定要识别出谁应该为哪个作业付费。另外，可能要用不同预算项目中的资金支付作业费用，例如根据资金的可用性选择预算项目。
云代理实例必须支持至少一种支付方案。例如，后付费、预付费（比如在预订服务时付费）或连续付费方案。
云服务在定价方面应该具有灵活性（可以随时间变动），应该有不同的价格表，比如使用量费用、固定费用、一次性费用和折扣。策略可以像下面这样：
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE < 240 * 60 * 60 (seconds), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (Euros) EVENT = "ONE_OFF SERVICE 1", RESOURCE_TYPE = "BLADE Type 4", ONE_OFF_COST = 1 |
为了满足云账单模块的基本非功能性需求，模块应该至少具有以下功能：
- 保证事务的安全性。
- 基于角色的身份验证。
- 通过审计跟踪进行活动分析。
尤其是，必须采取措施防止没有经过身份验证或授权的客户或冒名顶替者发送事件或触发账单流程。
通过分析一个云环境账单模块，您了解了在开发自己的云账单模块时应该考虑的一些事项。我解释了这个模块如何适应会计和账单服务，以及它如何适应整个云基础设施。您看到了账单策略的示例以及语法和语言，了解了规则/推论引擎的工作原理。我还简要介绍了对于账单模块需要考虑的功能性需求和基本的非功能性需求。
学习
-
这份教程讲解如何在 XML 文档中使用 Autonomic Computing Expression Language。
-
在 developerWorks 云开发人员资源 中，寻找应用程序和服务开发人员构建云部署项目的知识和经验，并分享自己的经验。
-
后续研究：了解如何访问 IBM Smart Business Development and Test on the IBM Cloud。
- 加入云计算讨论组，了解和讨论云计算的最新技术、解决方案、趋势等内容。
获得产品和技术
-
在 IBM Smart Business Development and Test on the IBM Cloud 上查看可用的 产品映像。
讨论
-
阅读 developerWorks 上所有精彩的云博客。
- 加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。