搜索​​​​

业务服务Business Service/BS是能够支持我们从外部数据来源获取数据强大的组件，在在大多数情况下，内置的现成组件就已经可以完成这项工作，但有时候我们还是需要写编码来自定义业务服务。在这样做的时候，有一些最佳实践供大家参考。 精益求精--业务服务的代码应该是最小化处理。这是由于如果在业务服务中发生任何错误，将不发送任何消息，从而将不创建任何跟踪。这使得它很难进行故障排除。相反，要尽可能快地完成Ensemble消息，并将其传递给适当的目标。有些人认为，如果有一个流进来，Ensemble消息应该包括一个流属性，然后由一个业务流程来解析这个流。(见文档中的例子3）还有人说，只要包括良好的错误检查，最小的处理就可以了。在这两种情况下，请记住，数据转换是存在的，可以在业务流程中使用，以便对该数据做进一步的翻译。这些转换不应该被从业务服务中调用。(参见文档中的示例1）。 可配置的目标：--在大多数情况下，业务服务的代码应该是一个可配置的目标，而不是将其硬编码到业务服务中。要做到这一点，你可以在业务服务类中创建一个名为TargetConfigNames的属性，其类型为Ens.DataType.ConfigName，使用SETTINGS参数并将此设置放在配置页上。 虽然这个属性不需要被命名为TargetConfigNames--但使用该名称与HL7组件中使用的内置设置相一致，这样做可以保持组件内的一致性。使用上面的代码只允许你选择一个目标。如果你需要向多个组件发送消息，有一些选项可以使这个设置成为多选的。请参考文档中的添加和删除设置，以了解更多关于如何做的内容。 你可以用下面的代码对该方法进行编码以处理多个目标： For iTarget=1:1:$L(..TargetConfigNames, ",") { Set tOneTarget=$ZStrip($P(..TargetConfigNames,",",iTarget),"<>W") Continue:""=tOneTarget $$$sysTRACE("Sending input Stream ...") set tSC = ..SendRequestAsync(tOneTarget, pRequest)} 欢迎分享更多最佳实践！

在软件开发和业务集成中，规则无处不在：会员折扣的计算规则、根据消息类型和内容将其路由到不同目标系统的路由规则。还有一个规则发挥重要作用的地方- 辅助决策规则，例如临床知识库和医疗质量指标规则。 规则经常需要随业务调整和知识积累进行调整，而规则的调整是业务和行业专家定的。如果规则是以代码硬编码的，这些调整需要程序员改动，一来不直观、需要业务专家与程序员大量的沟通成本，二来硬编码改动会对应用伤筋动骨，甚至带来风险，三来没法控制新规则生效的时间 – 总不能让程序员在新规则生效的那一刻去编译和部署吧。 InterSystems规则引擎可以帮助我们解决这些问题，于构建、执行和记录消息路由规则和普通的业务规则，带给应用和集成方案充分的灵活性和可用性。甚至业务专家和临床信息学家都可以通过低代码的、图形化的规则编辑器修改规则和指定规则生效和失效时间。 InterSystems规则引擎是InterSystems IRIS数据平台和Health Connect与Ensemble集成平台的组件。创建的规则可以被单独调用，也可以被业务流程调用。 本篇介绍规则的如何使用InterSystems规则编辑器创建规则和规则引擎执行规则的逻辑。 1. 规则基本概念 在设计规则前，先了解一下规则的基本概念。 1.1 上下文 上下文是用于规则定义的数据模型。用于临床决策支持的上下文通常需要患者信息、诊断、体征与观察、过敏、医嘱等信息来制定规则。例如糖化血红蛋白(观察)超过10%，要提示紧急警告。因为上下文提供了建立规则判据的主要*数据，所以它非常关键。 医疗行业的数据格式非常复杂，有HL7 V2这种分隔符分隔的字符串、有HL7 CDA这样的XML字符串/字符流、有新的基于JSON的FHIR、还有SQL二维表的记录。这些数据格式都可能会被用做建立规则的上下文模型。 *注：除了上下文中的数据，还可以使用规则临时变量的数据作为判据。 1.2 规则类型 规则可以用于很多场景，InterSystems规则引擎支持多种规则类型，包括： 用于消息路由的规则 根据上下文（请求消息）信息类型和内容，决定消息路由的目标 InterSystems提供多种开箱即用的消息路由规则类，分别对应HL7 V2消息、行业虚拟文档消息（DICOM、X12等）、XML虚拟文档消息和普通对象消息 普通的业务判断规则 根据上下文内容，决定返回结果 上下文可以是普通对象、HL7消息、医疗行业虚拟文档、XML文档、JSON等 管理警告规则 根据系统警告信息路由警告给不同的用户 我们会介绍路由规则和普通业务规则。 无论创建哪种规则，InterSystems技术平台都以类定义保存规则逻辑，也就是创建规则类，从而方便的导入/导出。 1.3 规则辅助类 规则辅助类约束规则定义并决定规则可以使用哪些操作，例如路由规则可以使用“发送”操作，而普通业务规则可以使用“返回”操作。 系统提供的每个规则类型都有对应的规则辅助类，例如虚拟文档路由规则的规则辅助类是：EnsLib.MsgRouter.VDocRuleAssist。 在选定创建的规则类型后，规则编辑器会自动选择对应的规则辅助类，除非特殊场景，无需自己选择。通常规则辅助类不需要修改，我们将会在高级规则特性介绍文章中介绍用户自定义辅助规则类。 1.4 规则集、规则、条件、行为 规则定义由四层构成： 规则集：一个规则定义中可以定义一到多个规则集，同时只有一个规则集生效。当有多个规则集时，通常它们代表不同的版本，通过规则集不同的生效起止日期进行分别。这样，可以事先生成好新的规则集、并定义好生效时间，规则引擎会在生效时间开始后自动启用新的规则集。 规则：一个规则集中，可以有一到多个规则，这些规则同时生效。例如在HL7 V2路由规则定义中，每个规则可以处理不同类型的V2消息。规则按其在规则集中的顺序执行，只要规则没有返回（return）行为，后面的规则会继续执行。 规则条件：在一个规则中，可以处理多个规则条件，用when和otherwise定义。规则条件定义需要满足的条件和满足条件时的行为(action)。同一级别条件下，when可以有多个，但otherwise最多有一个，代表所有when都不满足的条件。不同条件间相当于if...elseif关系，因此一个条件满足时，后面的条件不会再进行判断。 行为：在规则条件下，可以执行一个或多个行为(action)。其中返回行为(return)是特殊行为，执行到这个行为会直接返回，进而中断后续的规则、条件和行为的执行。 2．使用规则编辑器 InterSystems规则引擎提供图形化的规则编辑器，通过管理门户>Interoperability>构建>业务规则 访问它。 第一步要确定我们要建立什么类型规则：是消息路由规则，还是普通业务规则，亦或是管理警告规则？ 同时，规则是对象类，因此需要指定它的类包名（包）和类名（名称）。 2.1 消息路由规则的创建与编辑 本章介绍消息路由规则的创建与编辑，如果您是在找普通业务规则的创建方式，请跳到下一章。 消息路由流程本身是一种简单的业务流程，消息路由规则的上下文就是对应的业务流程对象，因此消息路由规则的上下文类型是固定的。 InterSystems提供4种开箱即用的消息路由规则，分别是： 路由规则类型 说明 上下文类 普通消息路由规则 用于用户自定义的对象类型消息的路由规则 EnsLib.MsgRouter.RoutingEngine HL7 消息路由规则 用于HL7 V2消息的路由规则 EnsLib.HL7.MsgRouter.RoutingEngine 虚拟文档消息路由规则 用于XML、EDIFACT等虚拟文档类型消息的路由规则 EnsLib.MsgRouter.VDocRoutingEngine 基于消息段的虚拟文档消息路由规则 用于XML、EDIFACT等虚拟文档类型消息的路由规则，基于消息段，而非完整消息 EnsLib.EDI.MsgRouter.SegmentedRoutingEngine 2.1.1 HL7 v2消息路由规则的创建和部署 HL7 v2消息是使用分割符分隔的字符串，在InterSystems数据平台上使用内建的虚拟文档来操作，因此可以将HL7 v2消息的段(Segment)和属性(Field)作为对象和属性方式操作，非常简单。同时，InterSystems数据平台提供开箱即用的路由production模版，直接基于模版编辑即可。 2.1.1.1 创建HL7 v2路由规则的方法 方法1: 使用HL7 v2 production模版向导创建 在production创建向导中，选择production类型为HL7消息发送。这时同时创建用户HL7 v2路由的production和对应路由规则类。这种方法最简单，如果目标就是建立一个路由HL7 v2的产品，推荐使用这个模版向导。 向导会自动应用模版，创建如下的HL7 v2路由产品，它带处理输入HL7文件的BS和输出HL7文件的BO、一个路由规则BP：MsgRouter和一个异常警告BP：Ens.Alert。 选择MsgRouter，在右侧的业务规则名称中可以看到，向导自动创建了名为HIP.Prod.HL7Router.RoutingRule的路由规则。点击后面的放大镜图标，即可对该规则进行编辑。 方法2: 直接使用规则向导创建规则 在规则创建向导中，选择规则类型为：HL7 Message Routing Rule。 2.1.1.2 编辑规则 使用HL7 v2 production模版向导创建的规则定义已经包含了一个规则集(ruleSet)，其中有一个规则(rule)，而该规则下只有一个条件(when)。使用规则向导创建的v2路由规则是完全空白的规则定义，只有一个规则集。 我们以HL7 v2 production模版向导创建的规则定义为例介绍规则的编辑。 在规则编辑器页面，右侧是规则辅助，由规则辅助类提供支持，列出可以执行的操作。选中ruleset、rule、条件(when/otherwise)和行为，都会显示不同的可以执行的操作和相应的解释。 规则集(ruleSet)是一系列的规则的组合。 规则集可以设置生效时间范围:effectiveBegin和effectiveEnd。如果未定义生效时间范围，规则定义编译后即刻生效。当定义多个ruleSet时，应该定义每个ruleSet的生效时间范围；如果有生效时间范围的重叠，会使用第一个生效的规则集。 规则集有名称 name，建议设置为有意义的规则集说明。 规则(rule)是一系列条件的组合。 选中ruleSet，点击+号就可以添加规则。 规则可以设置： 名称(name): 应该设置为有意义的字符串，例如” ADT文件消息处理”。 是否禁用(disabled)：默认是启用的(false)。 约束(constraint)：设置本规则的消息约束。双击constraint即可编辑。对于HL7 v2消息，可以对下列信息进行约束： 源(source)：对消息来源进行约束，本例中源被默认为HL7FileService，就是HL7文件源。如果这个路由规则需要处理多个HL7消息源，例如文件和TCP，可以把源约束删除掉。 Schema类别(Schema Category)：对HL7 v2消息的Schema版本进行约束。如果路由规则只处理特定版本的消息，可以进行选择，例如2.5.1。 文档名称(Document Name)：因为HL7 v2被作为虚拟文档对象进行处理，因此每种类型的v2消息都是一种虚拟文档。如果要对处理的v2消息类型进行约束，可以多选v2消息类型，例如ADT_A01和ADT_A03。 注意，这些约束项都是可选的。任何不符合约束的消息，都不会被路由，并且会被记录在规则日志(rule log)中。 规则条件(when/otherwise)设定条件(condition)。 选中rule，点击+号，即可增加条件when或otherwise。增加后，双击condition即可编辑。可以用在条件的判据数据就是上下文中的属性(数据)，在表达式编辑窗口的文本输入栏会有属性提示，打首字母就会提示，也可以打任意字符并删除，从而显示所有上下文可用属性。 HL7消息是一种虚拟文档*，因此有Document特殊变量用于访问其虚拟文档内的数据。如果在上一步的规则约束中选择了虚拟文档的类型，如ADT_A01，那么引擎还会在Document.{ 后提供所有对应HL7 v2虚拟文档的段和属性提示，如下图。 *注：关于虚拟文档，我将在下一篇文章中介绍。 在表达式编辑窗口中，点击op打开操作符向导，选择操作符，例如判等、大于、包含等。点击fx打开函数向导，选择函数，例如ConvertDateTime函数可以将HL7的时间格式(YYYYMMDDhhmmss)转为ODBC格式(YYYY-MM-DD hh:mm:ss)。也可以直接写表达式，而不使用这些操作符和函数向导。用户可以扩展自定义函数，见第二部分的规则函数扩展章节。 行为(action)定义了满足条件时的行为。 例如满足条件，将消息做模型转换后发送给外部HL7接口。在右侧的规则辅助窗口列出可以执行的行为。注意在同一个规则条件下，可以有多个行为，例如向多个目标发送不同的消息。 对于路由规则，通常的行为时发送(send)。发送前，选中转换(transform)可以选择发送前要执行的数据转换； 发送目标(target)会列出production中的所有业务操作和业务流程，可以多选。 注意1：规则(rule)也是一种行为，即满足条件时，可以执行子规则。 注意2：返回(return)行为会中断当前规则条件下的后续行为。 <<未完待续>>

InterSystems IRIS商业智能支持用多种方式使你的模型保持数据同步。这篇文章将展示如何构建和同步。当然有多种方式可以手动同步，但是这些是特殊案例，几乎所有的模型保持数据同步的方式都是通过构建和自动同步。 什么是构建？ 构建开始于将所有的数据从模型中移除。这样保证了构建的过程是从一个干净的起点开始的。接着构建会逐步从每个源类查询所有数据条目。这里会提取所有的数据条目，或者有限制的数据条目。当构建到对应的数据条目时候，被模型选择的数据会插入到模型中。最终，一旦所有的数据都被插入到模型里，索引会被构建。在这个过程中，模型是不可用的，数据也不能被查询。构建的执行过程是单线程或者多线程的。它可以被初始化于UI或者终端界面。UI界面会默认是多线程。从终端界面来运行构建过程会默认成多线程，除非过程中设置传入的参数。在更多的场景下，多线程构建是可行的。也有特殊的场景是不允许执行多线程构建的，那么构建过程只能通过单线程完成。 什么是同步？ 如果一个模型的源类是启动了DSTIME (参见文档)，它就可以被同步。DSTime允许通过更改源类来被追踪。当同步过程被启动，只有在模型中设定的需要变更的数据条目会被插入，更新或者删除。当同步过程正在运行，模型是可以用于查询数据的。同步机制只能通过终端界面来启动。它可以在UI界面的模型管理器中设置定时任务，但是不能够直接从UI界面执行。默认场景是，同步只能是单线程，但是也可以通过参数设置来启动多线程同步。 一个永远不会出错的办法是通过构建来初始化模型，然后通过同步机制来保持数据的更新。 差异回顾 构建 同步 多少数据需要更新？ 所有 只有变更的数据 可在UI界面操作？ 是 否 多线程 是，默认 是，非默认 模型是否可被使用 否(*1) 是 需要源类的变更 否 是，DSTIME需要开启 构建更新 （*1）从InterSystems IRIS 2020.1开始，选择性构建功能可以作为一个选项来构建模型了。这个功能将允许模型在构建过程中能够被使用。更多信息请参考 Getting Started with Selective Build 同步更新 从 InterSystems IRIS 2021.2开始，DSTIME会作为一个新的“条件”选项。这个改动将允许实施有条件的开启DSTIME选项，专门服务于特殊的场景和安装。

Hi 亲爱的开发者们， 在这篇帖子中，我们将向您展示如何善用开发者社区的各类标签（Tags），让我们充分利用这个开发者社区的选项吧！ 一个标签（Tag）就是一个描述帖子主题的单词或短语，是一种将开发者社区成员和专家与文章联系起来的方法，通过合理地运用标签（Tag），他们将能够讨论/给出正确的答案，将文章分类为具体的、定义明确的类别。 标签（Tag）也可以用来帮助你识别你感兴趣或相关的文章。 在开发者社区顶部的菜单中，你可以看到 标签（Tag）完整列表 标签（Tag）的类型和开发者社区的标签树（Tag Tree） 在开发者社区有两种标签： 标签组（Groups）– 所谓的主标签，用于标识广泛的主题，包括所有InterSystems技术。 标签（Tags）–用于更专门化主题的常规标签。 每个帖子必须至少有一个这样的组（Group）。你知道所有的组（Group）吗? 针对InterSystems technology的标签组 (9): 针对 Visual Studio Code的标签组: InterSystems开发者社区的官方声明标签组“official announcements” ： 来自Worldwide Response Center (WRC)的警告和警报标签组： Open Exchange的一个标签组(InterSystems软件解决方案和框架的InterSystems库)，另一个标签组是Global Masters(InterSystems游戏化平台)，还有一个另一个标签组是Partner Directory (合作伙伴目录，客户和合作伙伴的InterSystems平台)： 标签组Global Summit（全球峰会），这是InterSystems的年度盛会： 标签组Online Learning （在线学习）和Documentation（文档）: 供用户进行评论、发表意见、提供建议的标签组 DC Feedback： 与InterSystems技术相关的工作标签组 job opportunity announcements （工作机会发布）： 用以标记那些无法用前述标签归类的文章的标签组Others： 除了标签组（Group）之外，开发者社区成员还使用标签（Tags）来指定更多的帖子内容。 在 开发者社区标签树（Tag Tree），你会看到一些子标签（subtags），对标签的内容进行分类。 例如，在"语言（Languages）"标签下有如下子标签："C++", "Python", "JavaScript", "MultiValue Basic", "ObjectScript", "Java" and ".NET". 需要注意的是，为帖子加标签（Tags）并非强制性的，但是在发帖前你必须为帖子选择至少一个"标签组（Groups）”： 标签（Tags）归类： 你可以通过 开发者社区标签树（Tag Tree）以三种不同方式为标签归类： 1. 按热门程度: 标签组（Groups）和标签（Tags）根据它们在帖子中被使用的次数排列，这个数字会出现在每个标签（Tag）旁边的括号内。 例如，标签“Open Exchange” 出现在了368篇帖子中： 2. 按名称： 标签组（Groups）和标签（Tags）按字母顺序排列。 3. 按新增： 在这种模式下，新增标签组（Groups）和标签（Tags）会出现在最前面。 标签（Tag）页：按标签关注、排序、筛选文章 每个标签（Tag）都有自己的URL/网页，在那里你可以看到所有使用该标签的帖子。 例如， "XML" 标签（Tag）的标签页面是：https://cn.community.intersystems.com/tags/xml， 在这个页面展示了所有使用这一标签的文章： 在标签页面上，所有的帖子都可以通过不同的标准进行再次排列：按更新时间、按日期、按点赞、按查看数、按回复。 它们也可以按发布类型分类：公告、文章、问题、讨论、视频或工作。你需要到左上角的菜单，选择你要找的文章类型。 快来关注你感兴趣的标签（Tags）吧！ 如果你对某个主题感兴趣，你可以在开发者社区标签树（Tag Tree）中寻找它的标签，选择它，然后点击它旁边的“关注”按钮。当你关注了某一标签（Tags）时，你会收到所有使用该标签（Tags）的帖子的邮件。 我们推荐您可以关注以下标签： Best practices（最佳实践） | Tips and tricks（提示和技巧） | Beginner（初学者） | Tutorial（教程）. 那么，现在就来看看开发者社区标签树（Tag Tree）吧——一大波儿有趣的主题（标签）和各种有用的内容正在等着你！ 阅读所有与你感兴趣的主题相关的文章； 关注标签走，这样你就不会错过任何关于你最喜欢的话题的帖子了。 如果你有任何关于标签（Tags）的问题，或者你想@任何人，请在下面留下你的评论/建议!

在InterSystems IRIS数据平台管理门户中，有一些工具用于导入和导出数据。这些工具使用动态SQL，这意味着查询是在运行时准备和执行的。可以导入或导出的行的最大尺寸是3,641,144个字符。 你也可以使用%SQL.Import.Mgr类或LOAD DATA SQL命令导入数据，并使用%SQL.Export.Mgr类导出数据。 从文本文件中导入数据(.csv 和.txt) 你可以从一个文本文件中导入数据到一个合适的InterSystems IRIS类。当你这样做时，系统会在该类的表中创建并保存新的行。该类必须已经存在并且必须被编译。 步骤如下： 从管理门户中 选择系统资源管理器，然后选择SQL。用页面顶部的切换选项选择一个命名空间；这会显示可用的命名空间的列表。 在页面顶部，点击向导下拉列表，并选择数据导入。 在向导的第一页，首先指定外部文件的位置。对于导入文件所在的位置，点击要使用的服务器的名称。 然后输入文件的完整路径和文件名，文件可以是.csv 和 .txt格式。 然后选择你想要导入到schema的名称。 选择表名。 然后点击下一步。 在向导的第二页，选择需要导入数据的列。 然后点击下一步。 在向导的第三页，描述外部文件的格式。 在 "您的列所使用的分隔符? "中，点击与导入文件中的分隔符相对应的选项。 如果文件的第一行不包含数据，请点‘第一行是否包含列标题?’复选框。 对于字符串引号，点击表示该文件用于开始和结束字符串数据的引号定界符的选项。 对于日期格式，单击表示此文件中的日期格式的选项。 对于时间格式，点击表示此文件中的时间格式的选项。 对于时间戳格式，点击表示此文件中的时间戳格式的选项。 如果你不希望向导在导入时验证数据，请点击禁用验证复选框。 如果您不希望向导在导入时重建索引，请点击 ‘推迟 %SortBegin/%SortEnd 的索引构建?’ 复选框。如果勾选了 "延迟建立索引"，向导会在将导入的数据插入到表中之前调用类的%SortBegin方法。当导入完成后，向导会调用%SortEnd方法。没有进行验证（与带有%NOCHECK的INSERT相同）。这是因为当使用%SortBegin/%SortEnd时，在SQL插入过程中不能检查索引的唯一性。 可以选择点击预览数据，看看向导将如何解析这个文件中的数据。 点击 "下一步"。 审查你的条目并点击完成。该向导显示数据导入结果对话框。 点击关闭。或者点击给定的链接，查看背景任务页面。在这两种情况下，向导会启动一个后台任务来完成导入工作。 导出数据到文本文件 你可以将一个给定类的数据导出到一个文本文件。 步骤如下： 从管理门户中 选择系统资源管理器，然后选择SQL。用页面顶部的切换选项选择一个命名空间；这将显示可用的命名空间的列表。 在页面的顶部，点击向导下拉列表，选择数据导出。 在向导的第一页。 输入你要创建的文件的完整路径和文件名，以保存导出的数据。 从下拉列表中，选择你要导出数据的命名空间、模式名称和表名称。 可以选择从字符集下拉列表中选择一个字符集；默认是设备默认值。 然后点击下一步。 在向导的第二页，选择要导出的列。然后点击下一步。 在向导的第三页，描述外部文件的格式。 在 "用什么分隔符分隔你的列？"中，单击与该文件中的分隔符相对应的选项。 如果你想把列头作为文件的第一行导出，请点击 ‘是否导出列标题?’ 复选框。 对于字符串引号，点击一个选项来表示如何在这个文件中开始和结束字符串数据。 对于日期格式，点击一个选项来表示在这个文件中使用的日期格式。 对于时间格式，点击一个选项来指示在此文件中使用的时间格式。 可以选择点击预览数据，看看结果会是什么样子。 然后点击下一步。 审查你的条目并点击完成。向导会显示 "数据导出结果 "对话框。 点击关闭。或者点击给定的链接，查看背景任务页面，向导会启动一个后台任务来完成导出工作。

连接前准备： C++ 开发环境 InterSystems ODBC 驱动 （ODBC 驱动会随InterSystems IRIS安装包自动安装在服务器中） Connection String 步骤： Connection String：其中#include 用来导入需要使用的libraries，"Driver=InterSystems IRIS ODBC35;Host=localhost;Port=1972;Database=USER;UID=SQLAdmin;PWD=deployment-password;\0";是connection string。 #ifdef WIN32 #include <windows.h> #endif #include <sqlext.h> #ifdef UNICODE #include <sqlucode.h> #endif #include <stdio.h> int main() { RETCODE rc; /* Return code for ODBC functions */ HENV henv = NULL; /* Environment handle */ HDBC hdbc = NULL; /* Connection handle */ unsigned char szOutConn[600]; SQLSMALLINT *cbOutConn = 0; SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv); SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); char connect_cmd[255] = "Driver=InterSystems IRIS ODBC35;Host=localhost;Port=1972;Database=USER;UID=SQLAdmin;PWD=deployment-password;\0"; rc = SQLDriverConnect(hdbc, NULL, (SQLCHAR*) connect_cmd, SQL_NTS, szOutConn, 600, cbOutConn, SQL_DRIVER_COMPLETE); if (rc == SQL_SUCCESS) { printf("Successfully connected!!\n"); } else { printf("Failed to connect to IRIS\n"); exit(1); } SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); /* Free connection handle */ SQLFreeHandle(SQL_HANDLE_ENV, henv); /* Free environment handle */ return 0; }

开发者社区的同学们，大家好！ 我们一直以来都有一个想法——改进收集、分析和回应开发者社区成员们的产品改进请求的过程。我们知道，我们需要一个良好的用户体验，甚至更好的内部流程，来确保收集、听取和响应最好的想法。现在，这个想法终于实现了！ 我们在此向您介绍 InterSystems官方反馈门户 💡 >> InterSystems Ideas << 💡 InterSystems Ideas InterSystems Ideas是一个全新的、推动改进的渠道，您可以通过它向我们提交与InterSystems服务(文档、开发社区、全球大师等)相关的产品改进请求和想法，看看其他人提交了什么，为你喜欢的想法投票，投票给你最喜欢的，并从InterSystems获得反馈。 我们开始积极开发和推广创意门户网站InterSystems Ideas和您的创意。我们希望这可以为您提供一个公开的方式来获得我们的产品经理和社区成员的反馈。 ✅ 获得投票最多的想法会得到产品管理部门的评审。 来社区分享你的想法吧！通过投票和评论为其他想法提供贡献——投票越多，影响力越大! 点击看看创意网站 InterSystems Ideas portal!

现在，InterSystems **系统警报和监视**（简称 InterSystems _SAM_）第 1 版 (v1.0) 发布了预览版本。    InterSystems SAM v1.0 为基于 InterSystems IRIS 的产品提供现代化的监视解决方案。 其可对集群进行高级别查看，并且能够以单节点方式可视化深入探视指标，同时提供警报通知。 该第 1 个版本提供对一百多个 InterSystems IRIS 内核指标的可视化，并且用户可以根据自己的喜好扩展默认提供的 Grafana 模板。 V1.0 旨在成为简单直观的基准。 请进行尝试并向我们发送反馈，帮助我们使其变得更棒！ 从版本 2019.4 开始，SAM 可以显示来自基于 InterSystems 的实例中的信息 SAM 仅以容器格式提供。 您将需要 SAM 管理器容器，以及一小组额外的开源_组件_（Prometheus 和 Grafana），它们由组合文件自动添加。 可从以下位置获取 SAM 组件和 SAM 管理器社区版 * [WRC 预览页面](https://wrc.intersystems.com/wrc/coDistPreview.csp)：分别为“SAM 组件”和“SAM 管理器” * 如果您要在 docker-compose 运行之前下载，可通过外部源[SAM 组件 Github repo](https://github.com/intersystems-community/sam) & [Docker Hub 上的 SAM 管理器](https://hub.docker.com/_/intersystems-system-alerting-and-monitoring)（后一个链接可能在几个小时内不可用，但容器是可获取的）   如果您正在旅行，或偏爱通过语音收听有关什么是 SAM 方面的提问与回答，我们为您准备了以下播客： 可在[此处](https://docs.intersystems.com/sam/csp/docbook/Doc.View.cls?KEY=ASAM)找到 SAM 文档  

# 索引 下文按顺序列出了数据平台上容量计划和性能系列中的所有帖子。 也列出了我的其他帖子。 我将随着该系列中新帖子的增加进行更新。 #### 容量计划和性能系列 通常，每个帖子的内容都建立在上一个帖子的基础上，但您也可以直接浏览感兴趣的主题。 - [第 1 部分 - 入门：收集指标。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-1-篇) - [第 2 部分 - 研究收集的指标。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-2篇) - [第 3 部分 - 聚焦 CPU。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-3-篇：聚焦-cpu) - [第 4 部分 - 关注内存。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-第-4-篇-关注内存) - [第 5 部分 - 使用 SNMP 进行监控](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-第-5-篇-使用-snmp-进行监控) - [第 6 部分 - Caché 存储 IO 配置文件。](https://cn.community.intersystems.com/post/数据平台和性能-第-6-部分-caché-存储-io-配置文件) - [第 7 部分 - ECP的性能、可伸缩性和可用性 。](https://cn.community.intersystems.com/post/数据平台和性能-第-7-部分-用于确保性能、可伸缩性和可用性的企业缓存协议) - [第 8 部分 - 超融合基础架构容量和性能计划](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-8-hyper-converged-infrastructure-capacity) - [第 9 部分 - CachéVMware 最佳实践指南](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-第-9-篇-intersystems-iris-vmware-最佳实践指南) - [第 10 部分 - VM 备份和 Caché 冻结/解冻脚本](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-虚拟机备份和-caché-冻结解冻脚本) - [第 11 部分 - 虚拟化大型数据库 - VMware cpu 容量计划](https://cn.community.intersystems.com/post/虚拟化大型数据库-vmware-cpu-容量规划) #### 其他帖子 以下是我在社区中发布的与架构相关的帖子 - [使用内置 REST API监控 InterSystems IRIS - 使用 Prometheus 格式。](https://community.intersystems.com/post/monitoring-intersystems-iris-using-built-rest-api) - [示例：使用默认的 REST API 从 InterSystems IRIS 查看监视器指标](https://community.intersystems.com/post/example-review-monitor-metrics-intersystems-iris-using-default-rest-api) - [InterSystems 数据平台及性能 – 如何更新 pButton。](https://cn.community.intersystems.com/post/intersystems-数据平台和性能-–-如何更新-pbuttons) - [将 pButtons 数据提取到 csv 文件中以便于绘制图表。](https://cn.community.intersystems.com/post/将-pbuttons-数据提取到-csv-文件以便绘制图表) - [使用 Ansible 配置 Caché 应用程序 - 第 1 部分。](https://cn.community.intersystems.com/post/使用-ansible-预置-caché-应用程序-第-1) - [Windows、Caché 和病毒扫描程序。](https://community.intersystems.com/post/windows-cach%C3%A9-and-virus-scanners) - [ECP 魔术。](https://cn.community.intersystems.com/post/ecp-魔术) - [创建社区帖子的 Markdown 工作流程。](https://community.intersystems.com/post/markdown-workflow-creating-community-posts) - [Yape - 另一个 pButtons 提取程序（自动创建图表） ](https://cn.community.intersystems.com/post/yape-另一个-pbuttons-提取程序（自动创建图表）) - [加密一个数据库需要多久？](https://cn.community.intersystems.com/post/加密一个数据库需要多久？) - [最低限度的监控和告警解决方案](https://cn.community.intersystems.com/post/最低限度的监视和警报解决方案) - [LVM PE 条带化可最大化超融合存储吞吐量 ](https://cn.community.intersystems.com/post/lvm-pe-条带化使超聚合存储吞吐量最大化) - [使用 Yape 解包 pButton - 更新说明和快速指南](https://cn.community.intersystems.com/post/使用-yape-解包-pbuttons-更新说明和快速指南) Murray Oldfield InterSystems 技术架构师 请在社区关注@murray_oldfield 或我们中文版主

现在，InterSystems IRIS、IRIS for Health 和 IRIS Studio 的 2020.4 版发布了预览版本。由于是预览版本，因此我们渴望在下个月正式发布之前了解您对新版本的体验。 **InterSystems IRIS 数据平台 2020.4 **使开发、部署和管理增强型应用程序和业务流程（桥接数据和应用程序孤岛）变得更加容易。 其拥有众多新功能，包括： 面向应用程序和界面开发者的增强功能，包括： 使用 Oracle OpenJDK 和 AdoptOpenJDK 时均支持 Java SE 11 LTS 支持 JDBC 连接池 分段虚拟文档的路由规则新增“foreach”操作 面向数据库和系统管理员的增强功能，包括： ICM 现在支持部署系统警报和监视 (SAM) 以及 InterSystems API 管理器（IAM） 常见管理任务的 SQL 语法得到扩展 InterSystems 报告的部署得到简化    ** InterSystems IRIS for Health 2020.4 **包括 InterSystems IRIS 的所有增强功能。 另外，此版本还包括： 增强的 FHIR 支持，包括对 FHIR 配置文件的支持 支持 RMD IHE 配置文件 在 HL7 迁移工具中支持 DataGate   有关这些功能的更多详细信息，请参见产品文档： InterSystems IRIS 2020.4 文档及版本说明 InterSystems IRIS for Health 2020.4 文档及版本说明 由于这是 CD 版本，因此仅以 OCI（开放容器计划） 亦即 Docker 容器格式提供。  容器映像可用于面向 Linux x86-64 和 Linux ARM64 的 OCI 兼容运行时间引擎，如[支持的平台文档](https://docs.intersystems.com/iris20204/csp/docbook/platforms/index.html)中详述。   **企业版**容器映像及其所有相应组件都可以使用以下命从[ InterSystems 容器注册表](https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_containerregistry)中获得： docker pull containers.intersystems.com/intersystems/iris:2020.4.0.521.0 docker pull containers.intersystems.com/intersystems/irishealth:2020.4.0.521.0 有关可用映像的完整列表，请参阅[ ICR 文档](https://docs.intersystems.com/components/csp/docbook/Doc.View.cls?KEY=PAGE_containerregistry#PAGE_containerregistry_images)。 也可以使用以下命令从[ Docker 存储库](https://hub.docker.com/_/intersystems-iris-data-platform)提取**社区版**的容器映像： docker pull store/intersystems/iris-community:2020.4.0.521.0 docker pull store/intersystems/iris-community-arm64:2020.4.0.521.0 docker pull store/intersystems/irishealth-community:2020.4.0.521.0 docker pull store/intersystems/irishealth-community-arm64:2020.4.0.521.0 另外，可以通过 WRC 的[预览版本下载网站](https://wrc.intersystems.com/wrc/coDistPreview.csp)获取所有容器映像的 tarball 版本。   InterSystems IRIS Studio 2020.4 是 Microsoft Windows 支持的独立开发映像。 其可以与 InterSystems IRIS 和 IRIS for Health 版本 2020.4 及更低版本一起使用，还可以与 Caché 和 Ensemble 一起使用。 可以通过 WRC 的[预览下载网站](https://wrc.intersystems.com/wrc/coDistPreview.csp)进行下载。 此预览版本的内部版本号是 2020.4.0.521.0。

假设你想了解 InterSystems 在数据分析方面能提供什么。 你研究了理论，现在想要进行一些实践。 幸运的是，InterSystems 提供了一个项目：Samples BI，其中包含了一些很好的示例。 从 README 文件开始，跳过任何与 Docker 相关的内容，直接进行分步安装。 启动虚拟实例 安装 IRIS，按照说明安装 Samples BI，然后用漂亮的图表和表格让老板眼前一亮。 到目前为止还不错。 但是不可避免地，你需要进行更改。 事实证明，自己保留虚拟机存在一些缺点，交给云服务商保管是更好的选择。 Amazon 看起来很可靠，你只需创建一个 AWS 帐户（入门免费），了解到使用 root 用户身份执行日常任务是有害的，然后创建一个常规的具有管理员权限的 IAM 用户。 点击几下鼠标，就可以创建自己的 VPC 网络、子网和虚拟 EC2 实例，还可以添加安全组来为自己开放 IRIS Web端口 (52773) 和 ssh 端口 (22)。 重复 IRIS 和 Samples BI 的安装。 这次使用 Bash 脚本，如果你喜欢，也可以使用 Python。 再一次让老板刮目相看。 但是无处不在的 DevOps 运动让你开始了解基础架构即代码，并且你想要实现它。 你选择了 Terraform，因为它是众所周知的，而且它的方法非常通用，只需微小调整即可适合各种云提供商。 使用 HCL 语言描述基础架构，并将 IRIS 和 Samples BI 的安装步骤转换到 Ansible。 然后再创建一个 IAM 用户使 Terraform 正常工作。 全部运行一遍。 获得工作奖励。 渐渐地你会得出结论，在我们这个[微服务](https://martinfowler.com/articles/microservices.html)时代，不使用 Docker 就太可惜了，尤其是 InterSystems 还会告诉你[怎么做](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ADOCK_iris)。 返回到 Samples BI 安装指南并阅读关于 Docker 的几行内容，似乎并不复杂： $ docker pull intersystemsdc/iris-community:2019.4.0.383.0-zpm$ docker run --name irisce -d --publish 52773:52773 intersystemsdc/iris-community:2019.4.0.383.0-zpm$ docker exec -it irisce iris session irisUSER>zpmzpm: USER>install samples-bi   将浏览器定向到 http://localhost:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER 后，再次去老板那里，因为做得好而获得一天假期。 然后你开始明白，“docker run”只是开始，至少需要使用 docker-compose。 没问题： $ cat docker-compose.ymlversion: "3.7"services: irisce: container_name: irisce image: intersystemsdc/iris-community:2019.4.0.383.0-zpm ports: - 52773:52773$ docker rm -f irisce # We don’t need the previous container$ docker-compose up -d   这样你使用 Ansible 安装了 Docker 和 docker-compose，然后运行了容器，如果机器上还没有映像，则会下载一个映像。 最后安装了 Samples BI。 你一定喜欢 Docker，因为它是各种内核素材的又酷又简单的接口。 你开始在其他地方使用 Docker，并且经常启动多个容器。 还发现容器必须经常互相通信，这就需要了解如何管理多个容器。 终于，你发现了 Kubernetes。 从 docker-compose 快速切换到 Kubernetes 的一个方法是使用 [kompose](https://kompose.io/)。 我个人更喜欢简单地从手册中复制 Kubernetes 清单，然后自己编辑，但是 kompose 在完成小任务方面做得很好： $ kompose convert -f docker-compose.ymlINFO Kubernetes file "irisce-service.yaml" createdINFO Kubernetes file "irisce-deployment.yaml" created   现在你有了可以发送到某个 Kubernetes 集群的部署和服务文件。 你发现可以安装 minikube，它允许你运行一个单节点 Kubernetes 集群，这正是你现阶段所需要的。 在摆弄一两天 minikube 沙盒之后，你已经准备好在 AWS 云中的某处使用真实的 Kubernetes 部署。   设置 我们一起来进行吧。 此时，我们做以下几个假设： 首先，我们假设你有一个 AWS 帐户，你[知道其 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)，并且未使用 root 凭据。 你创建了一个具有[管理员权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)且只能以编程方式访问的 IAM 用户（我们称之为“my-user”），并存储了其凭据。 你还创建了另一个具有相同权限的 IAM 用户，名为“terraform”：  Terraform 将以它的名义进入你的 AWS 帐户，并创建和删除必要资源。 这两个用户的广泛权限将通过演示来说明。 你在本地保存了这两个 IAM 用户的凭据： $ cat ~/.aws/credentials[terraform]aws_access_key_id = ABCDEFGHIJKLMNOPQRSTaws_secret_access_key = ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123[my-user]aws_access_key_id = TSRQPONMLKJIHGFEDCBAaws_secret_access_key = TSRQPONMLKJIHGFEDCBA01234567890123   注意：不要复制和粘贴上面的凭据。 它们在这里作为示例提供，不再存在。 请编辑 ~/.aws/credentials 文件并引入你自己的记录。 其次，我们将在文中使用虚拟的 AWS 帐户 ID (01234567890) 和 AWS 区域“eu-west-1”。 可以随意使用其他区域。 第三，我们假设你知道 AWS 不是免费的，你需要为使用的资源付费。 接下来，您已经安装了 AWS CLI 实用程序，以便与 AWS 进行命令行通信。 你可以尝试使用 aws2，但你需要在 kube 配置文件中特别设置 aws2 的用法，如这里所述。 你还安装了 kubectl 实用程序来与 AWS Kubernetes 进行命令行通信。 并且你也针对 docker-compose.yml 安装了 kompose 实用程序，来转换 Kubernetes 清单。 最后，你创建了一个空的 GitHub 仓库，并将其克隆到主机上。 我们将其根目录引用为 。 在此仓库中，我们将创建并填充三个目录：.github/workflows/、k8s/ 和 terraform/。 请注意，所有相关代码都在 github-eks-samples-bi 仓库中复制，以简化拷贝和粘贴。 我们继续。   AWS EKS 预置 我们已经在文章使用 Amazon EKS 部署简单的基于 IRIS 的 Web 应用程序中知道了 EKS。 那时，我们以半自动方式创建了一个集群。 即，我们在一个文件中描述集群，然后从本地机器手动启动 eksctl 实用程序，该实用程序根据我们的描述创建集群。 eksctl 是为创建 EKS 集群而开发的，它非常适合概念验证实现，但对于日常使用来说，最好使用更通用的工具，例如 Terraform。 AWS EKS 简介是一个非常好的资源，其中介绍了创建 EKS 集群所需的 Terraform 配置。 花一两个小时熟悉一下，决不会是浪费时间。 你可以在本地操作 Terraform。 为此，你需要一个二进制文件（在撰写本文时，我们使用最新的 Linux 版本 0.12.20），并且 IAM 用户“terraform”需要有足够的权限才能让 Terraform 进入 AWS。 创建目录 /terraform/ 以存储 Terraform 代码： $ mkdir /terraform$ cd /terraform   你可以创建一个或多个 .tf 文件（它们会在启动时合并）。 只需复制并粘贴 AWS EKS 简介中的代码示例，然后运行如下命令： $ export AWS_PROFILE=terraform$ export AWS_REGION=eu-west-1$ terraform init$ terraform plan -out eks.plan   你可能会遇到一些错误。 如果遇到的话，可以在调试模式下操作，但记得稍后关闭该模式： $ export TF_LOG=debug$ terraform plan -out eks.plan$ unset TF_LOG   这个经验会很有用，你很可能会启动一个 EKS 集群（使用“terraform apply”进行该操作）。 在 AWS 控制台中查看：    觉得厌烦时就清理掉： $ terraform destroy   然后进入下一阶段，开始使用 Terraform EKS 模块，尤其它也基于同一 EKS 简介。 在 examples/ 目录中，你将看到如何使用它。 你还会在那里找到其他示例。 我们对示例进行了一定的简化。 以下是主文件，其中调用了 VPC 创建和 EKS 创建模块： $ cat /terraform/main.tfterraform {  required_version = ">= 0.12.0"  backend "s3" {    bucket         = "eks-github-actions-terraform"    key            = "terraform-dev.tfstate"    region         = "eu-west-1"    dynamodb_table = "eks-github-actions-terraform-lock"  }} provider "kubernetes" {  host                   = data.aws_eks_cluster.cluster.endpoint  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)  token                  = data.aws_eks_cluster_auth.cluster.token  load_config_file       = false  version                = "1.10.0"} locals {  vpc_name             = "dev-vpc"  vpc_cidr             = "10.42.0.0/16"  private_subnets      = ["10.42.1.0/24", "10.42.2.0/24"]  public_subnets       = ["10.42.11.0/24", "10.42.12.0/24"]  cluster_name         = "dev-cluster"  cluster_version      = "1.14"  worker_group_name    = "worker-group-1"  instance_type        = "t2.medium"  asg_desired_capacity = 1} data "aws_eks_cluster" "cluster" {  name = module.eks.cluster_id} data "aws_eks_cluster_auth" "cluster" {  name = module.eks.cluster_id} data "aws_availability_zones" "available" {} module "vpc" {  source               = "git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master"   name                 = local.vpc_name  cidr                 = local.vpc_cidr  azs                  = data.aws_availability_zones.available.names  private_subnets      = local.private_subnets  public_subnets       = local.public_subnets  enable_nat_gateway   = true  single_nat_gateway   = true  enable_dns_hostnames = true   tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"  }   public_subnet_tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"    "kubernetes.io/role/elb" = "1"  }   private_subnet_tags = {    "kubernetes.io/cluster/${local.cluster_name}" = "shared"    "kubernetes.io/role/internal-elb" = "1"  }} module "eks" {  source = "git::https://github.com/terraform-aws-modules/terraform-aws-eks?ref=master"  cluster_name     = local.cluster_name  cluster_version  = local.cluster_version  vpc_id           = module.vpc.vpc_id  subnets          = module.vpc.private_subnets  write_kubeconfig = false   worker_groups = [    {      name                 = local.worker_group_name      instance_type        = local.instance_type      asg_desired_capacity = local.asg_desired_capacity    }  ]   map_accounts = var.map_accounts  map_roles    = var.map_roles  map_users    = var.map_users}   我们再仔细看一下 main.tf 中的“_terraform_”块： terraform {  required_version = ">= 0.12.0"  backend "s3" {    bucket         = "eks-github-actions-terraform"    key            = "terraform-dev.tfstate"    region         = "eu-west-1"    dynamodb_table = "eks-github-actions-terraform-lock"  }}   这里需要指出，我们将遵守不低于 Terraform 0.12 的语法（与早期版本相比有了很大变化），同时，Terraform 不应该将其状态存储在本地，而是远程存储在 S3 存储桶中。 不同的人可以从不同的地方更新 terraform 代码确实很方便，这意味着我们需要能够锁定用户的状态，因此我们使用 dynamodb 表添加了一个锁。 有关锁定的更多信息，请参见状态锁定页面。 由于存储桶的名称在整个 AWS 中应该是唯一的，因此你不能再使用名称“eks-github-actions-terraform”。 请想一个你自己的名称，并确保它没有被占用（应该收到 NoSuchBucket 错误）： $ aws s3 ls s3://my-bucket调用 ListObjectsV2 操作时发生错误 (AllAccessDisabled)：对此对象的所有访问均已禁用$ aws s3 ls s3://my-bucket-with-name-that-impossible-to-remember调用 ListObjectsV2 操作时发生错误 (NoSuchBucket)：指定的存储桶不存在   想好一个名称，创建存储桶（我们这里使用 IAM 用户“terraform”。 它拥有管理员权限，因此可以创建存储桶），并为其启用版本管理（这在配置出错时能让你省心）： $ aws s3 mb s3://eks-github-actions-terraform --region eu-west-1make_bucket: eks-github-actions-terraform$ aws s3api put-bucket-versioning --bucket eks-github-actions-terraform --versioning-configuration Status=Enabled$ aws s3api get-bucket-versioning --bucket eks-github-actions-terraform{  "Status": "Enabled"}   对于 DynamoDB，不需要唯一性，但你需要先创建一个表： $ aws dynamodb create-table                                                                                     \  --region eu-west-1                                                                                                           \  --table-name eks-github-actions-terraform-lock                                              \  --attribute-definitions AttributeName=LockID,AttributeType=S                \  --key-schema AttributeName=LockID,KeyType=HASH                                   \  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5      注意，如果 Terraform 操作失败，你可能需要从 AWS 控制台手动删除锁。 但这样做时要小心。 对于 main.tf 中的 eks/vpc 模块，引用 GitHub 上提供的模块很简单： git::https://github.com/terraform-aws-modules/terraform-aws-vpc?ref=master   现在看一下另外两个 Terraform 文件（variables.tf 和 outputs.tf）。 第一个文件保存了 Terraform 变量： $ cat /terraform/variables.tfvariable "region" {  default = "eu-west-1"} variable "map_accounts" {  description = "Additional AWS account numbers to add to the aws-auth configmap. See examples/basic/variables.tf for example format."  type        = list(string)  default     = []} variable "map_roles" {  description = "Additional IAM roles to add to the aws-auth configmap."  type = list(object({    rolearn  = string    username = string    groups   = list(string)  }))  default = []} variable "map_users" {  description = "Additional IAM users to add to the aws-auth configmap."  type = list(object({    userarn  = string    username = string    groups   = list(string)  }))  default = [    {      userarn  = "arn:aws:iam::01234567890:user/my-user"      username = "my-user"      groups   = ["system:masters"]    }  ]}   这里最重要的部分是将 IAM 用户“my-user”添加到 map_users 变量中，但你应该使用自己的帐户 ID 替换 01234567890。 这有什么用？ 当通过本地 kubectl 客户端与 EKS 通信时，它会向 Kubernetes API 服务器发送请求，每个请求都要经过身份验证和授权过程，这样 Kubernetes 就可以知道谁发送了请求，以及它们可以做什么。 因此 Kubernetes 的 EKS 版本会要求 AWS IAM 帮助进行用户身份验证。 如果发送请求的用户列在 AWS IAM 中（这里我们指向其 ARN），请求将进入授权阶段，该阶段将由 EKS 自己处理，但要依据我们的设置。 这里要指出的是，IAM 用户“my-user”非常酷（组“system: masters”）。 最后，output.tf 文件描述了 Terraform 在完成工作后应该打印的内容： $ cat /terraform/outputs.tfoutput "cluster_endpoint" {  description = "Endpoint for EKS control plane."  value       = module.eks.cluster_endpoint} output "cluster_security_group_id" {  description = "Security group ids attached to the cluster control plane."  value       = module.eks.cluster_security_group_id} output "config_map_aws_auth" {  description = "A kubernetes configuration to authenticate to this EKS cluster."  value       = module.eks.config_map_aws_auth}   Terraform 部分的描述完成。 我们很快就会回来，看看如何启动这些文件。   Kubernetes 清单 到目前为止，我们已经解决了在哪里启动应用程序的问题。 现在我们来看看要运行什么。 回想一下 /k8s/ 目录中的 docker-compose.yml（我们重命名了服务，添加了几个不久就会被 kompose 用到的标签） ： $ cat /k8s/docker-compose.ymlversion: "3.7"services:  samples-bi:    container_name: samples-bi    image: intersystemsdc/iris-community:2019.4.0.383.0-zpm    ports:    - 52773:52773    labels:      kompose.service.type: loadbalancer      kompose.image-pull-policy: IfNotPresent   运行 kompose，然后添加下面突出显示的内容。 删除注释（使内容更容易理解）： $ kompose convert -f docker-compose.yml --replicas=1$ cat /k8s/samples-bi-deployment.yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  replicas: 1  strategy:    type: Recreate  template:    metadata:      labels:        io.kompose.service: samples-bi    spec:      containers:      - image: intersystemsdc/iris-community:2019.4.0.383.0-zpm        imagePullPolicy: IfNotPresent        name: samples-bi        ports:        - containerPort: 52773        resources: {}        lifecycle:          postStart:            exec:              command:              - /bin/bash              - -c              - |                echo -e "write\nhalt" > test                until iris session iris < test; do sleep 1; done                echo -e "zpm\ninstall samples-bi\nquit\nhalt" > samples_bi_install                iris session iris < samples_bi_install                rm test samples_bi_install        restartPolicy: Always   我们使用 Recreate 更新策略，这意味着先删除 pod，然后重新创建。 这对于演示目的是允许的，让我们可以使用更少的资源。 我们还添加了 postStart 挂钩，该挂钩在 pod 启动后立即触发。 我们等待至 IRIS 启动，然后从默认的 zpm-repository 安装 samples-bi 包。 现在我们添加 Kubernetes 服务（同样没有注释）： $ cat /k8s/samples-bi-service.yamlapiVersion: v1kind: Servicemetadata:  labels:    io.kompose.service: samples-bi  name: samples-bispec:  ports:  - name: "52773"    port: 52773    targetPort: 52773  selector:    io.kompose.service: samples-bi  type: LoadBalancer   是的，我们将在“默认”命名空间中部署，该命名空间适合演示。 好了，现在我们知道了运行_位置_和_内容_。 还剩下_方式_需要了解。   GitHub Actions 工作流程 我们不需要每件事都从头开始做，而是创建一个工作流程，类似于[使用 GitHub Actions 在 GKE 上部署 InterSystems IRIS 解决方案](https://community.intersystems.com/post/deploying-intersystems-iris-solution-gke-using-github-actions)中所述的工作流程。 这次，我们不必担心构建容器。 GKE 特定的部分已替换为特定于 EKS。 粗体部分与接收提交消息和在条件步骤中使用它有关： $ cat /.github/workflows/workflow.yamlname: Provision EKS cluster and deploy Samples BI thereon:  push:    branches:    - master # Environment variables.# ${{ secrets }} are taken from GitHub -> Settings -> Secrets# ${{ github.sha }} is the commit hashenv:  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  AWS_REGION: ${{ secrets.AWS_REGION }}  CLUSTER_NAME: dev-cluster  DEPLOYMENT_NAME: samples-bi jobs:  eks-provisioner:    # Inspired by:    ## https://www.terraform.io/docs/github-actions/getting-started.html    ## https://github.com/hashicorp/terraform-github-actions    name: Provision EKS cluster    runs-on: ubuntu-18.04    steps:    - name: Checkout      uses: actions/checkout@v2     - name: Get commit message      run: |        echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})     - name: Show commit message      run: echo $commit_msg     - name: Terraform init      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'init'        tf_actions_working_dir: 'terraform'     - name: Terraform validate      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'validate'        tf_actions_working_dir: 'terraform'     - name: Terraform plan      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'plan'        tf_actions_working_dir: 'terraform'     - name: Terraform plan for destroy      if: "contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'plan'        args: '-destroy -out=./destroy-plan'        tf_actions_working_dir: 'terraform'     - name: Terraform apply      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'apply'        tf_actions_working_dir: 'terraform'     - name: Terraform apply for destroy      if: "contains(env.commit_msg, '[destroy eks]')"      uses: hashicorp/terraform-github-actions@master      with:        tf_actions_version: 0.12.20        tf_actions_subcommand: 'apply'        args: './destroy-plan'        tf_actions_working_dir: 'terraform'   kubernetes-deploy:    name: Deploy Kubernetes manifests to EKS    needs:    - eks-provisioner    runs-on: ubuntu-18.04    steps:    - name: Checkout      uses: actions/checkout@v2     - name: Get commit message      run: |        echo ::set-env name=commit_msg::$(git log --format=%B -n 1 ${{ github.event.after }})     - name: Show commit message      run: echo $commit_msg     - name: Configure AWS Credentials      if: "!contains(env.commit_msg, '[destroy eks]')"      uses: aws-actions/configure-aws-credentials@v1      with:        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}        aws-region: ${{ secrets.AWS_REGION }}     - name: Apply Kubernetes manifests      if: "!contains(env.commit_msg, '[destroy eks]')"      working-directory: ./k8s/      run: |        aws eks update-kubeconfig --name ${CLUSTER_NAME}        kubectl apply -f samples-bi-service.yaml        kubectl apply -f samples-bi-deployment.yaml        kubectl rollout status deployment/${DEPLOYMENT_NAME}   当然，我们需要设置“terraform”用户的凭据（从 ~/.aws/credentials 文件中获取），让 Github 使用它的机密：    注意工作流程的突出显示部分。 我们可以通过推送包含短语“[destroy eks]”的提交消息来销毁 EKS 集群。 请注意，我们不会使用这样的提交消息来运行“kubernetes apply”。 运行管道，但首先要创建一个 .gitignore 文件： $ cat /.gitignore.DS_Storeterraform/.terraform/terraform/*.planterraform/*.json$ cd $ git add .github/ k8s/ terraform/ .gitignore$ git commit -m "GitHub on EKS"$ git push   在 GitHub 仓库页面的“Actions”选项卡上监视部署过程。 请等待成功完成。 第一次运行工作流程时，“Terraform apply”步骤需要 15 分钟左右，大约与创建集群的时间一样长。 下次启动时（如果未删除集群），工作流程会快很多。 你可以将此签出： $ cd $ git commit -m "Trigger" --allow-empty$ git push   当然，最好检查一下我们做了什么。 这次可以在你的笔记本电脑上使用 IAM“my-user”的凭据： $ export AWS_PROFILE=my-user$ export AWS_REGION=eu-west-1$ aws sts get-caller-identity$ aws eks update-kubeconfig --region=eu-west-1 --name=dev-cluster --alias=dev-cluster$ kubectl config current-contextdev-cluster $ kubectl get nodesNAME                                                                               STATUS   ROLES      AGE          VERSIONip-10-42-1-125.eu-west-1.compute.internal   Ready          6m20s     v1.14.8-eks-b8860f $ kubectl get poNAME                                                       READY        STATUS      RESTARTS   AGEsamples-bi-756dddffdb-zd9nw    1/1               Running    0                      6m16s $ kubectl get svcNAME                   TYPE                        CLUSTER-IP        EXTERNAL-IP                                                                                                                                                         PORT(S)                    AGEkubernetes        ClusterIP               172.20.0.1                                                                                                                                                                                443/TCP                    11msamples-bi         LoadBalancer     172.20.33.235    a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com    52773:31047/TCP  6m33s   访问 _[http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?$NAMESPACE=USER](http://a2c6f6733557511eab3c302618b2fae2-622862917.eu-west-1.elb.amazonaws.com:52773/csp/user/_DeepSee.UserPortal.Home.zen?%24NAMESPACE=USER) _（将链接替换为你的外部 IP），然后输入“_system”、“SYS”并更改默认密码。 您应该看到一系列 BI 仪表板：    点击每个仪表板的箭头可以深入了解：    记住，如果重启 samples-bi pod，所有更改都将丢失。 这是有意的行为，因为这是演示。 如果你需要保留更改，我在 github-gke-zpm-registry/k8s/statefulset.tpl 仓库中创建了一个示例。 完成后，删除你创建的所有内容： $ git commit -m "Mr Proper [destroy eks]" --allow-empty$ git push   结论 在本文中，我们将 eksctl 实用程序替换成 Terraform 来创建 EKS 集群。 这是向“编纂”您的所有 AWS 基础架构迈出的一步。 我们展示了如何使用 Github Actions 和 Terraform 通过 git push 轻松部署演示应用程序。 我们还向工具箱中添加了 kompose 和 pod 的 postStart 挂钩。 这次我们没有展示 TLS 启用。 我们将在不久的将来完成这项任务。

Amazon Web Services (AWS) 云提供广泛的云基础设施服务，例如计算资源、存储选项和网络，这些都非常实用：按需提供，几秒内就可用，采用即付即用定价的模式。 新服务可得到快速配置，且前期无需支出大量资金。 这使得大企业、初创公司、中小型企业以及公共部门的客户可以访问他们所需的基础设施，从而快速响应不断变化的业务需求。 更新日期：2019 年 10 月 15 日 以下概述和详细信息由 Amazon 提供，并可以在此处找到。 概述 AWS 全球基础设施 AWS 云基础设施围绕区域和可用性地区 (AZ) 构建。 区域就是地球上的物理位置，我们拥有多个 AZ。 AZ 由一个或多个离散的数据中心组成，每个数据中心都拥有冗余电源、网络和连接，并安置在单独的设施中。 这些 AZ 可让您能够以比在单个数据中心更高的可用性、容错能力和可伸缩性运行生产应用程序和数据库。 有关 AWS 全球基础设施的详细信息，可在此处找到。AWS 安全性和合规性 云端的安全性与您本地数据中心的安全性非常相似，只是没有维护设施和硬件的成本。 在云端，您无需管理物理服务器或存储设备。 相反，您使用基于软件的安全工具来监控和保护进出云资源的信息流。 AWS 云实现了共享责任模型。 虽然 AWS 管理云的安全性，但您负责云中的安全性。 这意味着您保留了对您选择实施的安全性的控制，以保护您自己的内容、平台、应用程序、系统和网络，与您在现场数据中心中的做法没有区别。 有关 AWS 云安全的详细信息，可在此处找到。 AWS 为其客户提供的 IT 基础设施是按照最佳安全实践和各种 IT 安全标准进行设计和管理的。有关 AWS 遵守的保证计划的完整列表，可在此处找到。 AWS 云平台 AWS 由多种云服务组成，您可以根据您的业务或组织需求进行组合使用。 以下小节按类别介绍了 InterSystems IRIS 部署中常用的主要 AWS 服务。 还有许多其他服务也可能对您的具体应用有着潜在用途。 请务必根据需要加以研究。 要访问这些服务，您可以使用 AWS 管理控制台、命令行界面或软件开发套件 (SDK)。 AWS 云平台 组件 详细信息 AWS 管理控制台 有关 AWS 管理控制台的详细信息，可在此处找到。 AWS 命令行界面 有关 AWS 命令行界面 (CLI) 的详细信息，可在此处找到。 AWS 软件开发套件 (SDK) 有关 AWS 软件开发套件 (SDK) 的详细信息，可在此处找到。 AWS 计算 有许多选项可供选择： 有关 Amazon Elastic Cloud Computing (EC2) 的详细信息，可在此处找到 有关 Amazon EC2 Container Service (ECS) 的详细信息，可在此处找到 有关 Amazon EC2 Container Registry (ECR) 的详细信息，可在此处找到 有关 Amazon Auto Scaling 的详细信息，可在此处找到 AWS 存储 有许多选项可供选择： 有关 Amazon Elastic Block Store (EBS) 的详细信息，可在此处找到 有关 Amazon Simple Storage Service (S3) 的详细信息，可在此处找到 有关 Amazon Elastic File System (EFS) 的详细信息，可在此处找到 AWS 网络 有许多选项可供选择： 有关 Amazon Virtual Private Cloud (VPC) 的详细信息，可在此处找到 有关 Amazon Elastic IP Addresses 的详细信息，可在此处找到 有关 Amazon Elastic Network Interfaces 的详细信息，可在此处找到 有关 Amazon Enhanced Networking for Linux 的详细信息，可在此处找到 有关 Amazon Elastic Load Balancing (ELB) 的详细信息，可在此处找到 有关 Amazon Route 53 的详细信息，可在此处找到 InterSystems IRIS 示例架构 本文部分内容阐述了面向 AWS 的 InterSystems IRIS 部署示例，旨在为特定应用程序的部署抛砖引玉。这些示例可用作很多部署方案的指南。此参考架构拥有非常强大的部署选项，从最小规模的部署，到满足计算和数据需求的大规模可伸缩工作负载，不一而足。 本文介绍了高可用性和灾难恢复选项以及其他建议的系统操作。个体可对这些进行相应的修改以支持其组织的标准实践和安全策略。 针对您的特定应用，就基于 AWS 的 InterSystems IRIS 部署，您可联系 InterSystems 进一步探讨。示例参考架构 以下示例架构按照容量和功能逐步升级的顺序讲述了几种不同的配置，分别为小型开发/生产/大型生产/分片集群生产。先从中小型配置讲起，然后讲述具有跨地区高可用性以及多区域灾难恢复的大规模可缩放性解决方案。此外，还讲述了一个将 InterSystems IRIS 数据平台的新的分片功能用于大规模处理并行 SQL 查询的混合工作负载的示例。 小型开发配置 在本示例中，显示了一个能支持 10 名开发人员和 100GB 数据的小型开发环境，这基本是最小规模的配置。只要适当地更改虚拟机实例类型并增加 EBS 卷存储，即可轻松支持更多的开发人员和数据。 这足以支持开发工作，并让您熟悉 InterSystems IRIS 功能以及 Docker 容器的构建和编排（如果需要的话）。小型配置通常不采用具有高度可用性的数据库镜像，但是如果需要高可用性，则可随时添加。 小型配置示例图 示例图 2.1.1-a 显示了图表 2.1.1-b 中的资源。其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。 图 2.1.1-a：小型开发架构示例 下列 AWS VPC 资源是针对最小规模的配置提供的。可根据需求添加或删除 AWS 资源。 小型配置 AWS 资源 下表提供了小型配置 AWS 资源的示例。 图 2.1.1-b：小型配置 AWS 资源表示例 需要考虑适当的网络安全和防火墙规则，以防止对 VPC 的不必要访问。Amazon 提供网络安全最佳做法供您入门使用，可在此处找到： https://docs.aws.amazon.com/vpc/index.html#lang/en_us https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html#best-practices 注意：VM 实例需要公共 IP 地址才能访问 AWS 服务。 AWS 建议使用防火墙规则来限制传入到这些 VM 实例的流量，尽管这种做法可能会引起一些问题。 如果您的安全策略确实需要内部 VM 实例，则您需要在网络上手动设置 NAT 代理和相应的路由，以便内部实例可以访问互联网。 务必要明确，您无法使用 SSH 直接完全连接到内部 VM 实例。 要连接到此类内部机器，必须设置具有外部 IP 地址的堡垒机实例，然后通过它建立隧道。 可以配置堡垒主机，以提供进入 VPC 的外部入口点。 有关使用堡垒主机的详细信息，可在此处找到： https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/ https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html 生产配置 在本示例中，展示了一个规模较大的生产配置，其采用 InterSystems IRIS 数据库镜像功能来支持高可用性和灾难恢复。 此配置包括 一对InterSystems IRIS 数据库服务器同步镜像，该镜像服务器在区域 1 内分为两个可用性地区，用于自动故障转移，在区域 2 内的第三个 DR 异步镜像成员用于灾难恢复，以防万一整个 AWS 区域宕机。 有关采用多 VPC 连接的多区域的详细信息，可在此处找到。 InterSystems Arbiter 和 ICM 服务器部署在单独的第三个地区，以提高弹性。 此示例架构还包括一组可选的负载均衡 web 服务器，用于支持启用 Web 的应用程序。这些使用 InterSystems 网关的 Web 服务器可以根据需要进行缩放。 生产配置示例图 示例图 2.2.1-a 显示了图表 2.2.1-b 中的资源。 其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。 图 2.2.1-a：具有高可用性和灾难恢复的生产架构示例 建议将以下 AWS VPC 资源作为支持 Web 应用程序生产工作负载的最低配置。可根据需求添加或删除 AWS 资源。 生产配置 AWS 资源 下表提供了生产配置 AWS 资源的示例。 .png) 图 2.2.1-b：生产配置 AWS 资源表（续） 大型生产配置 在本示例中，提供了一个大规模可伸缩性配置。该配置通过扩展 InterSystems IRIS 功能也引入使用 InterSystems 企业缓存协议 (ECP) 的应用程序服务器，实现对用户的大规模横向伸缩。本示例甚至包含了更高级别的可用性，因为即使在数据库实例发生故障转移的情况下，ECP 客户端也会保留会话细节。多个 AWS 可用性地区与基于 ECP 的应用程序服务器和部署在多个区域中的数据库镜像成员一起使用。此配置能够支持每秒数千万次的数据库访问和数万亿字节数据。 生产配置示例图 示例图 2.3.1-a 显示了图表 2.3.1-b 中的资源。 其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。 此配置中包括一对故障转移镜像，四个或更多的 ECP 客户端（应用程序服务器），以及每个应用程序服务器对应一个或多个 Web 服务器。 故障转移数据库镜像对在同一区域中的两个不同 AWS 可用性地区之间进行划分，以提供故障域保护，而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中，以提高弹性。 灾难恢复扩展至第二个 AWS 区域和可用性地区，与上一示例中的情况类似。如果需要，可以将多个 DR 区域与多个 DR 异步镜像成员目标一起使用。 图 2.3.1-a：采用 ECP 应用程序服务器的大型生产架构示例 建议将以下 AWS VPC 项目中的资源作为分片集群部署的最低配置。可根据需求添加或删除 AWS 资源。 大型生产配置 AWS 资源 下表提供了大型生产配置 AWS 资源的示例。 图 2.3.1-b：具有 ECP 应用程序服务器 AWS 资源的大型配置表 图 2.3.1-b：具有 ECP 应用程序服务器 AWS 资源的大型配置表（续） 图 2.3.1-b：具有 ECP 应用程序服务器 AWS 资源的大型配置表（续） * * * 采用 InterSystems IRIS 分片集群的生产配置 在此示例中，提供了一个针对 SQL 混合工作负载的横向伸缩性配置，其包含 InterSystems IRIS 新的分片集群功能，可实现 SQL 查询和数据表的跨多个系统的大规模横向伸缩。本文的第 9 节将详细讨论 InterSystems IRIS 分片集群及其功能。 采用分片集群的生产配置示例图 示例图 2.4.1-a 显示了图表 2.4.1-b 中的资源。 其中包含的网关只是示例，可做相应地调整以适应您组织的标准网络实践。 此配置中包括四对镜像，它们为数据节点。每对故障转移数据库镜像在同一区域中的两个不同 AWS 可用性地区之间进行划分，以提供故障域保护，而 InterSystems Arbiter 和 ICM 服务器则部署在单独的第三地区中，以提高弹性。 此配置允许从集群中的任何数据节点使用所有的数据库访问方法。大型 SQL 表数据在物理上跨所有数据节点进行分区，以实现查询处理和数据卷的大规模并行。将所有这些功能组合在一起，就可以支持复杂的混合工作负载，比如大规模分析 SQL 查询及插入的新数据，所有这一切均在一个 InterSystems IRIS 数据平台中执行。 图 2.4.1-a：具有高可用性的采用分片集群的生产配置示例 注意，上面图表中以及下表“资源类型”列中的术语“EC2”是一个表示 AWS 虚拟服务器实例的 AWS 术语，将在本文的 3.1节中做进一步介绍。 它并不表示或暗示第 9 章所描述的集群架构中对“计算节点”的使用。 建议将以下 AWS VPC 中的资源作为分片集群部署的最低配置。可根据需求添加或删除 AWS 资源。 采用分片集群 AWS 资源的生产配置 下表提供了采用分片集群 AWS 资源的生产配置的示例。 图 2.4.1-b：采用分片集群 AWS 资源的生产配置示例表 * * * 云概念简介 Amazon Web Services (AWS) 为基础设施即服务 (IaaS) 提供功能丰富的云环境，使其具备完备的功能，支持所有的 InterSystems 产品，包括支持基于容器的 DevOps 及最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、系统操作、高可用性、灾难恢复、安全控制和其他管理程序。本文档将介绍所有云部署涉及的三个主要组件：计算、存储和网络。 计算引擎（虚拟机） AWS EC2 中存在数个针对计算引擎资源的选项，以及众多虚拟 CPU 和内存规范及相关存储选项。在 AWS EC2 中值得注意的一点是，对给定机器类型中 vCPU 数量的引用等于一个 vCPU，其是虚拟机监控程序层上物理主机中的一个超线程。 就本文档的目的而言，将使用 m5* 和 r5* EC2 实例类型，这些实例类型在大多数 AWS 部署区域中广泛可用。但是，对于在缓存内保留了大量数据的超大型工作数据集而言，使用 x1 *（拥有大内存）或 i3 *（具有 NVMe 本地实例存储）等其他专门的实例类型才是最佳的选择。 有关 AWS 服务水平协议 (SLA) 的详细信息，可在此处找到。 磁盘存储 与 InterSystems 产品最直接相关的存储类型是持久性磁盘类型，但是，如果了解并适应数据可用性限制，本地存储可以用于高水平的性能。 还有其他一些选项，例如 S3（存储桶）和 Elastic File Store (EFS)，但是这些选项更特定于个别应用程序的需求，而非支持 InterSystems IRIS 数据平台的操作。 与大多数其他云提供商一样，AWS 对可与单个计算引擎关联的持久性存储的量施加了限制。这些限制包括每个磁盘的最大容量、关联到每个计算引擎的持久性磁盘的数量，以及每个持久性磁盘的 IOPS 数量，对单个计算引擎实例 IOPS 设置上限。此外，对每 GB 磁盘空间设有 IOPS 限制，因此有时需要调配更多磁盘容量才能达到所需的 IOPS 速率。 这些限制可能会随着时间而改变，可在适当时与 AWS 确认。 磁盘卷有三种类型的持久性存储类型：EBS gp2（SSD）、EBS st1（HDD）和 EBS io1（SSD）。标准 EBS gp2 磁盘更适合于那些要求可预测性低延迟 IOPS 和高吞吐量的生产工作负载。标准持久性磁盘对于非生产开发和测试或归档类型的工作负载，是一种更经济的选择。 有关各种磁盘类型及限制的详细信息，可在此处找到。 VPC 网络 强烈建议采用虚拟私有云 (VPC) 网络来支持 InterSystems IRIS 数据平台的各个组件，同时提供正确的网络安全控制、各种网关、路由、内部 IP 地址分配、网络接口隔离和访问控制。本文档中提供了一个详细的 VPC 示例。 有关 VPC 网络和防火墙的详细信息，可在此处找到。 * * * 虚拟私有云 (VPC) 概述 此处提供有关 AWS VPC 的详细信息。 在大多数大型云部署中，采用多个 VPC 将各种网关类型与以应用为中心的 VPC 进行隔离，并利用 VPC 对等进行入站和出站通信。 有关适合您的公司使用的子网和任何组织防火墙规则的详细信息，强烈建议您咨询您的网络管理员。本文档不阐述 VPC 对等方面的内容。 在本文档提供的示例中，使用 3 个子网的单一 VPC 用于提供各种组件的网络隔离，以应对各种 InterSystems IRIS 组件的可预测延迟和带宽以及安全性隔离。 网络网关和子网定义 本文档的示例中提供了两种网关，以支持互联网和安全 VPN 连接。要求每个入口访问都具有适当的防火墙和路由规则，从而为应用程序提供足够的安全性。有关如何使用 VPC 路由表的详细信息，可在此处找到。 提供的示例架构中使用了 3 个子网，它们与 InterSystems IRIS 数据平台一起使用。这些单独的网络子网和网络接口的使用为上述 3 个主要组件的每一个提供了安全控制、带宽保护和监视方面的灵活性。有关创建具有多个网络接口的虚拟机实例的详细信息，可在此处找到。 这些示例中包含的子网： 用户空间网络用于入站连接用户和查询 分片网络用于分片节点之间的分片间通信 镜像网络通过同步复制和单个数据节点的自动故障转移实现高可用性。 注意：仅在单个 AWS 区域内具有低延迟互连的多个地区之间，才建议进行故障转移同步数据库镜像。 区域之间的延迟通常太高，无法提供良好的用户体验，特别是对于具有高更新率的部署更如此。 内部负载均衡器 大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力，这种地址通常用在自动化数据库故障转移设计中。 为了解决这一问题，InterSystems IRIS 中增强了几种最常用的连接方法，尤其是 ECP 客户端和 Web 网关，从而不再依赖 VIP 功能使它们实现镜像感知和自动化。 xDBC、直接 TCP/IP 套接字等连接方法，或其他的直接连接协议，均需要使用类 VIP 地址。为了支持这些入站协议，InterSystems 数据库镜像技术使用称作<span class="Characteritalic" style="font-style:italic">mirror_status.cxw</span>的健康检查状态页面为 AWS 中的这些连接方法提供自动化故障转移，以与负载均衡器进行交互，实现负载均衡器的类 VIP 功能，仅将流量重定向至活动的主镜像成员，从而在 AWS 内实现完整且强大的高可用性设计。 有关 AWS Elastic 负载均衡器 (ELB) 的详细信息，可在此处找到。 图 4.2-a：无虚拟 IP 地址的自动故障转移 此处提供了使用负载均衡器实现类 VIP 功能的详细信息。 示例 VPC 拓扑 下图 4.3-a 中的 VPC 布局组合了所有组件，具有以下特点： 利用一个区域内的多个地区实现高可用性 提供两个区域进行灾难恢复 利用多个子网进行网络隔离 包括分别用于 VPC 对等、互联网和 VPN 连接的单独网关 使用云负载均衡器进行镜像成员的 IP 故障转移 请注意，在 AWS 中，每个子网必须完全位于一个可用性地区内，并且不能跨越地区。 因此，在下面的示例中，需要正确定义网络安全性或路由规则。 有关 AWS VPC 子网的详细信息，可在此处找到。 图 4.3-a：VPC 网络拓扑示例 * * * 持久性存储概述 如简介中所述，建议使用 AWS Elastic Block Store（EBS）卷，尤其是 EBS gp2 卷类型。之所以推荐 EBS gp2 卷，是由于其拥有更高的读写 IOPS 速率以及低的延迟，适合于事务性和分析性数据库工作负载。在某些情况下，可使用本地 SSD，但值得注意的是，本地 SSD 的性能提升会在可用性、耐用性和灵活性方面做出一定的权衡。 可在此处找到本地 SSD 数据持久性方面的详细信息，您可了解何时保存本地 SSD 数据以及何时不保存它们。 LVM PE 条带化 与其他的云提供商一样，AWS 在 IOPS、空间容量和每个虚拟机实例的设备数量方面都施加了众多存储限制。有关当前的限制，请查阅 AWS 文档，可在此处找到。 由于这些限制的存在，使用 LVM 条带化实现数据库实例的单个磁盘设备的 IOPS 最大化变得非常必要。在提供的此示例虚拟机实例中，建议使用以下磁盘布局。与 SSD 持久性磁盘相关的性能限制可在此处找到。 注意：尽管 AWS 资源功能经常更改，但每个 Linux EC2 实例当前最多有 40 个 EBS 卷，因此请查阅 AWS 文档以了解当前限制。 图 5.1-a：LVM 卷组分配示例 LVM 条带化的优势在于可以将随机的 IO 工作负载分散到更多的磁盘设备并继承磁盘队列。以下是如何在 Linux 中将 LVM 条带化用于数据库卷组的示例。本示例在一个 LVM PE 条带中使用 4 个磁盘，物理盘区 (PE) 大小为 4MB。或者，如果需要，可以使用更大的 PE 容量。 步骤 1：根据需要创建标准性磁盘或 SSD 持久性磁盘 步骤 2：使用“lsblk -do NAME,SCHED”将每个磁盘设备的 IO 调度器设置为 NOOP 步骤 3：使用“lsblk -do KNAME,TYPE,SIZE,MODEL”识别磁盘设备 步骤4：使用新的磁盘设备创建磁盘卷组 vgcreate s 4M 示例： <span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span> 步骤 4：创建逻辑卷 lvcreate n -L -i -I 4MB 示例： <i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i> 步骤 5：创建文件系统 mkfs.xfs K 示例： <i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i> 步骤 6：装载文件系统 使用以下装载条目编辑 /etc/fstab /dev/mapper/vg_iris_db-lv_irisdb01 /vol-iris/db xfs defaults 0 0 装载 /vol-iris/db 使用上表，每个 InterSystems IRIS 服务器将具有以下配置：2 个 SYS 磁盘、4 个 DB 磁盘、2 个主日志磁盘、2 个备用日志磁盘。 图 5.1-b：InterSystems IRIS LVM 配置 为了增长，LVM 允许在需要的情况下不中断地扩展设备和逻辑卷。有关持续管理和扩展 LVM 卷的最佳做法，请查阅 Linux 文档。 注意：强烈建议同时为数据库和写入映像日志文件启用异步 IO。 请参阅社区文章获取在 Linux 上启用的详细信息。 * * * 配置 InterSystems IRIS 新增了 InterSystems Cloud Manager (ICM)。ICM 执行众多任务，并提供许多用于配置 InterSystems IRIS 数据平台的选项。 ICM 作为 Docker 映像提供，其拥有配置强大的、基于 AWS 云的解决方案所需的一切。 ICM 当前支持以下平台上的配置： Amazon Web Services，包括 GovCloud (AWS / GovCloud) Google Cloud Platform (GCP) Microsoft Azure Resource Manager，包括 Government (ARM / MAG) VMware vSphere (ESXi) ICM 和 Docker 可以从台式机/笔记本电脑工作站运行，也可以具有中央专用的适度“配置”服务器和中央存储库。 ICM 在应用程序生命周期中的作用是“定义->配置->部署->管理” 有关安装和使用 ICM 及 Docker 的详细信息，可在此处找到。 注意：任何云部署都非必须使用 ICM。完全支持传统的 tar-ball 分布式安装和部署方法。但是，建议使用 ICM，以简化云部署中的配置和管理。 容器监视 I针对基于容器的部署，CM 包括两个基本的监视工具： Rancher 和 Weave Scope。 默认情况下不会部署这两个工具，需要在默认的文件中使用监视器字段指定。有关使用 ICM 进行监视、编排和调度的详细信息，可在此处找到。 有关 Rancher 的概述和相关文档，可在此处找到。 有关 Weave Scope 的概述和相关文档，可在此处找到。 * * * 高可用性 InterSystems 数据库镜像可在任何云环境中提供最高级别的可用性。AWS 不会为单个 EC2 实例提供任何可用性保证，因此数据库镜像是必需的，其还要与负载均衡和自动伸缩组结合使用。 前面的部分讨论了云负载均衡器如何通过数据库镜像为虚拟 IP（类 VIP）功能提供自动 IP 地址故障转移。云负载均衡器使用前面内部负载均衡器部分中提到的 mirror_status.cxw 健康检查状态页面。数据库镜像有两种模式——自动故障转移同步镜像、异步镜像。在本示例中，将介绍同步故障转移镜像。有关镜像的详细信息，可在此处找到。 最基本的镜像配置是仲裁器控制配置中的一对故障转移镜像成员。仲裁器放置在同一区域内的第三个地区中，以防止潜在的地区可用性中断影响仲裁器和其中一个镜像成员。 在网络配置中，有多种方法专供设置镜像。在本示例中，我们将使用本文档前述网络网关和子网定义部分中定义的网络子网。下一部分内容将提供 IP 地址方案示例，并且基于本部分内容，将仅描述网络接口和指定的子网。 图 7-a：采用仲裁器的镜像配置示例 * * * 灾难恢复 InterSystems 数据库镜像将支持灾难恢复的高可用性功能扩展到另一个 AWS 地理区域，以在整个 AWS 区域万一宕机的情况下支持操作弹性。应用程序如何忍受此类中断取决于恢复时间目标 (RTO) 和恢复点目标 (RPO)。这些将为设计适当的灾难恢复计划进行的分析提供初始框架。以下链接中的指南提供了您在为自己的应用程序制定灾难恢复计划时要考虑的事项。 https://aws.amazon.com/disaster-recovery/ 以下链接中的指南提供了您在为自己的应用制定灾难恢复计划时要考虑的事项。 异步数据库镜像 InterSystems IRIS 数据平台的数据库镜像提供强大的功能，可在 AWS 可用性地区和区域之间异步复制数据，以帮助支持您的灾难恢复计划的 RTO 和 RPO 目标。有关异步镜像成员的详细信息，可在此处找到。 与上述高可用性部分中讲述的内容相似，云负载均衡器也使用上文内部负载均衡器部分中提到过的 mirror_status.cxw 健康检查状态页面为虚拟 IP（类 VIP）功能提供自动化 IP 地址故障转移，以进行 DR 异步镜像。 在本示例中，将介绍 DR 异步故障转移镜像，并介绍 AWS Route53 DNS 服务，以便为上游系统和客户端工作站提供单个 DNS 地址，而不管您的 InterSystems IRIS 部署是否在哪个可用性区域或地区中运行。 有关 AWS Route53 的详细信息，可在此处找到。 图 8.1-a：采用 AWS Route53 的 DR 异步镜像示例 在上述示例中，两个区域的 Elastic 的负载均衡器 (ELB) （前端 InterSystems IRIS 实例）的 IP 地址都提供给了 Route53，它会将流量仅定向到承担主要镜像的镜像成员，而不论其位于哪个可用性地区或区域。 * * * 分片集群 InterSystems IRIS 包括一套全面的功能来伸缩您的应用程序，根据您的工作负载的性质以及所面临的特定挑战，可单独或者组合应用这些功能。 分片功能是这些功能中的一种，可跨多个服务器对数据及其关联的缓存进行分区，从而为查询和数据引入提供灵活、高性价比的性能扩展，同时通过高效的资源利用最大化基础设施的价值。 InterSystems IRIS 分片集群可以为各种应用提供显著的性能优势，尤其对于工作负载包括以下一项或多项的应用更是如此： 大容量或高速数据写入，或两者的组合。 相对较大的数据集、返回大量数据的查询，或两者的组合。 执行大量数据处理的复杂查询，例如扫描磁盘上大量数据或涉及大量计算工作的查询。 这些场景的使用都是分片集群的潜在优势，但组合的应用场景可能会最大化分片集群的优势起来使用它们可能会增加优势。 例如，这 3 个场景的组合——快速引入大量数据、大型数据集、检索和处理大量数据的复杂查询——使得当今的许多分析性工作负载非常适合进行分片。 注意，这些特征都与数据有关；InterSystems IRIS 分片的主要功能是缩放数据量。 不过，当涉及某些或所有这些与数据相关的场景的工作负载也经历大量用户的超高查询量时，分片群集也能提供用户量伸缩功能。 分片也可以与纵向伸缩相结合。 操作概述 分片架构的核心是跨多个系统对数据及其关联的缓存进行分区。 分片集群跨多个 InterSystems IRIS 实例（称为数据节点）以行方式对大型数据库表进行物理上的横向分区，同时允许应用通过任何节点透明地访问这些表，但仍将整个数据集看作一个逻辑并集。 该架构具有 3 个优点： 并行处理 查询在数据节点上并行运行，各个结果被应用程序所连接的节点合并、组合，然后以完整的查询结果返回给应用程序，这在许多情况下显着提高了执行速度。 分区缓存 每个数据节点都有自己的缓存，专用于它存储的分片表数据分区，而非为整个数据集提供服务的单个实例的缓存，这大大降低了缓存溢出的风险，以及强制进行读取性能较低的磁盘的风险。 并行加载 数据可以并行加载到数据节点上，这降低了插入工作负载和查询工作负载之间缓存和磁盘的争用，从而提高两者的性能。 有关 InterSystems IRIS 分片集群的详细信息，可在此处找到。 分片组件和实例类型 分片集群包含至少一个数据节点，如果特定性能或工作负载有需要，则可添加一定数量的计算节点。 这两种节点类型提供简单的构建基块，显示了一个简单、透明和高效的缩放模型。 数据节点 数据节点存储数据。 在物理层面，分片表[1]数据分布在集群中的所有数据节点上，非分片表数据仅物理存储在第一个数据节点上。 这种区分对用户是透明的，唯一可能的例外是，第一个节点的存储消耗可能比其他节点略高，但是由于分片表数据通常会超出非分片表数据至少一个数量级，因此这种差异可以忽略不计。 需要时，可以跨集群重新均衡分片表数据，这通常发生在添加新的数据节点后。 这将在节点之间移动数据的“存储桶”，以实现数据的近似均匀分布。 在逻辑层面，未分片的表数据和所有分片的表数据的并集在任何节点上都可见，因此客户端会看到整个数据集，这与其连接哪个节点无关。 元数据和代码也会在所有数据节点之间共享。 分片集群的基本架构图仅由在集群中看起来统一的数据节点组成。 客户端应用程序可以连接到任何节点，并且获得像数据是存储在本地一样体验。 图 9.2.1-a：基本分片集群图 [1]为方便起见，术语“分片表数据”在整个文档中用于表示支持分片的任何数据模型的“盘区”数据（标记为已分片）。 术语“未分片表数据”和“未分片数据”用于表示处于可分片盘区但却未这样标记的数据，或表示尚不支持分片的数据模型。 计算节点 对于要求低延迟（可能存在不断涌入数据的冲突）的高级方案，可以添加计算节点以提供用于服务查询的透明缓存层。 计算节点缓存数据。 每个计算节点都与一个数据节点关联，为其缓存相应的分片表数据，此外，它还根据需要缓存非分片表数据，以满足查询的需要。 图 9.2.2-a：具有计算节点的分片集群 由于计算节点物理上并不存储任何数据，其只是支持查询执行，因此可对其硬件配置文件进行调整以满足需求，调整方法如：通过强调内存和 CPU、将存储空间保持在最低限度等。 当“裸露”应用程序代码在计算节点上运行时，引入数据会被驱动程序 (xDBC, Spark) 直接或被分片管理器代码间接转发到数据节点。 分片集群说明 分片集群部署有多种组合。下列各图说明了最常见的部署模型。这些图不包括网络网关及细节，仅侧重于分片群集组件。 基本分片集群 下图是在一个区域和一个地区中部署了 4 个数据节点的最简单分片群集。AWS Elastic 负载均衡器 (ELB) 用于将客户端连接分发到任何一个分片集群节点。 图 9.3.1-a：基本分片集群 在此基本模型中，除了 AWS 为单个虚拟机及其连接的 SSD 持久性存储提供的弹性或高可用性外，没有其他弹性或高可用性。建议使用两个单独的网络接口适配器，一则为入站客户端连接提供网络安全隔离，二则为客户端流量和分片集群通信之间提供带宽隔离。 具有高可用性的基本分片集群 下图是在一个区域中部署了 4 个镜像数据节点的最简单分片集群，每个节点的镜像在地区之间进行了划分。AWS 负载均衡器用于将客户端连接分发到任何分片集群节点。 InterSystems 数据库镜像的使用带来了高可用性，其会在该区域内的第二地区中维护一个同步复制的镜像。 建议使用 3 个单独的网络接口适配器，一方面为入站客户端连接提供网络安全隔离，另一方面为客户端流量、分片集群通信、节点对之间的同步镜像流量之间提供带宽隔离。 图 9.3.2-a：具有高可用性的基本分片集群 此部署模型也引入了本文前面所述的镜像仲裁器。 具有单独计算节点的分片集群 下图采用单独的计算节点和 4 个数据节点扩展了分片集群，以此来应对大量的用户/查询并发。云负载均衡器服务器池仅包含计算节点的地址。数据更新和数据插入将像以前一样继续直接更新到数据节点，以维持超低延迟性能，并避免由于实时数据插入而在查询/分析工作负载之间造成资源的干扰和拥挤。 使用此模型，可以根据计算/查询和数据插入的规模单独微调资源分配，从而在“适时”需要的地方提供最佳资源，实现经济而简单的解决方案，而非只是进行计算或数据的调整，浪费不必要的资源。 计算节点非常适合直接使用 AWS 自动伸缩分组（亦称自动伸缩），允许基于负载的增加或减少自动从托管实例组添加或删除实例。 自动伸缩的工作原理为：负载增加时，将更多的实例添加到实例组（扩展）；对实例的需求降低时将其删除（缩减）。 有关 AWS 自动伸缩的详细信息，可在此处找到。 图 9.3.3-a：具有单独计算节点和数据节点的分片集群 自动伸缩可帮助基于云的应用程序轻松应对流量增加的情况，并在资源需求降低时降低成本。 只需简单地定义策略，自动伸缩器就会根据测得的负载执行自动伸缩。 * * * 备份操作 备份操作有多个选项。以下 3 个选项可供您通过 InterSystems IRIS 进行 AWS 部署。 下面的前 2 个选项（下文详细说明）采用快照类型的过程，该过程会在创建快照之前将数据库写入操作挂起到磁盘上，然后在快照成功后恢复更新。 可采取以下高级别步骤通过任一快照方法来创建洁净的备份： 通过数据库冻结外部 API 调用暂停对数据库的写入。 创建操作系统和数据磁盘的快照。 通过解冻外部 API 调用恢复数据库写入。 将快照存档备份到备份位置 有关冻结/解冻 外部API 的详细信息，可在此处找到。 注意：本文档未包含备份示例脚本，但您可定期检查发布到 InterSystems 网站上开发者社区的示例。 www.community.intersystems.com 第三个选项是 InterSystems 在线备份。这是小型部署的入门级方法，具有非常简单的用例和界面。但是，随着数据库的增大，建议将使用快照技术的外部备份作为最佳做法，因为其具有以下优势：备份外部文件、更快的恢复时间，以及企业范围的数据和管理工具。 可以定期添加诸如完整性检查之类的其他步骤，以确保洁净且一致的备份。 决定使用哪种选项取决于您组织的运营要求和策略。InterSystems 可与您详细讨论各种选项。 AWS Elastic Block Store (EBS) 快照备份 可以使用 AWS CLI 命令行 API 以及 InterSystems 冻结/解冻外部API 功能来实现备份操作。 这允许实现真正的 24x7 全天候操作弹性保证，并确保干净的常规备份。有关管理、创建和自动化 AWS EBS 快照的详细信息，可在此处找到。 逻辑卷管理器 (LVM) 快照 或者，可以在 VM 本身中部署单个备份代理，利用文件级备份，并结合逻辑卷管理器 (LVM) 快照，来使用市面上的许多第三方备份工具。 该模型的主要优点之一是能够对基于 Windows 或 Linux 的 VM 进行文件级恢复。此解决方案需要注意的几点是，由于 AWS 和大多数其他 IaaS 云提供商都不提供磁带媒体，因此所有的备份存储库对于短期归档均基于磁盘，并利用 Blob 或存储桶类型的低成本存储来进行长期保留 (LTR)。强烈建议您使用此方法来使用支持重复数据删除技术的备份产品，以最有效地利用基于磁盘的备份存储库。 这些具有云支持的备份产品的示例包括但不限于：Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。InterSystems 不会验证或认可一种备份产品是否优于其他产品。 在线备份 对于小型部署，内置在线备份工具也是可行的选择。该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据，然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 有关在线备份的详细信息，可在此处找到。 在 AWS 中，在线备份完成后，必须将备份输出文件和系统正在使用的所有其他文件复制到该虚拟机实例之外的其他存储位置。存储桶/对象存储是很好的选择。 使用 AWS Single Storage Space（S3）存储桶有两种选择。 直接使用 AWS CLI 脚本 API 来复制和操作新创建的在线备份（和其他非数据库）文件 有关详细信息可在此处找到。 装载 Elastic File Store (EFS) 卷，将其类似地用作持久性磁盘，这样做成本低。 有关 EFS 的详细信息，可在此处找到。 * * *

本文提供了一个参考架构，作为示例说明基于 InterSystems Technologies（适用于 Caché、Ensemble、HealthShare、TrakCare 以及相关的嵌入式技术，例如 DeepSee、iKnow、Zen 和 Zen Mojo）提供的强大性能和高可用性应用。Azure 有两种用于创建和管理资源的不同部署模型：Azure Classic 和 Azure Resource Manager。 本文中的详细信息基于 Azure Resource Manager (ARM) 模型。 摘要 Microsoft Azure 云平台为基础设施即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将阐述所有这些方面。 性能 在 Azure ARM 中，有多个可用于计算虚拟机 (VM) 的选项以及相关的存储选项，与 InterSystems 产品最直接相关的是网络连接 的IaaS 磁盘，其作为 VHD 文件存储在 Azure 页面的 Blob 存储中。 还有其他几个选项，例如_ Blob（块）、文件_等，但是这些选项更特定于单个应用程序的要求，而非支持 Caché 的操作。 磁盘存储有两种类型的存储：“高级存储”和“标准存储”。 高级存储更适合这样的生产工作负载：要求保证可预测的低延迟每秒输入/输出操作 (IOP) 和吞吐量。 标准存储是针对非生产或存档类型工作负载的更经济选择。 选择特定的 VM 类型时务必小心，因为并非所有的 VM 类型都可以访问高级存储。 虚拟 IP 地址和自动故障转移 大多数 IaaS 云提供商缺乏提供虚拟 IP (VIP) 地址的能力，这种地址通常用在数据库故障转移设计中。 为解决这一问题，Caché 中增强了几种最常用的连接方法，尤其是 ECP 客户端和 CSP 网关，从而不再依赖 VIP 功能使它们实现镜像状态感知。 xDBC、直接 TCP/IP 套接字等连接方法，或其他的直接连接协议，均需要使用 VIP。 为解决这些问题，InterSystems 数据库镜像技术使用 API 与 Azure 内部负载均衡器（ILB）交互以实现类 VIP 功能，使得 Azure 中的那些连接方法实现自动故障转移，从而在 Azure 中提供完整而强大的高可用性设计 。 有关详细信息，请参见社区文章无虚拟 IP 地址的数据库镜像。 备份操作 无论使用传统的文件级备份，还是基于快照的备份，在云部署中执行备份都面临着挑战。 如今，在 Azure ARM 平台中，使用 Azure Backup 和 Azure Automation Run Books 配合 InterSystems 外部冻结及解冻 API 功能，即可实现这一切，从而实现真正的 24x7 全天候操作弹性并确保干净的常规备份。 或者，可以在 VM 本身中部署备份代理，利用文件级备份，并结合逻辑卷管理器 (LVM) 快照，来使用市面上的许多第三方备份工具。 示例架构 作为本文档的一部分，这里为您提供一个示例 Azure 架构，作为您特定应用部署的入门参考，并可用作各种部署的可能性的指南。 此参考架构显示了一个强大的 Caché 数据库部署，其中包括可实现高可用性的数据库镜像成员、使用 InterSystems 企业缓存协议（ECP）的应用程序服务器、使用 InterSystems CSP 网关的 Web 服务器，以及内部和外部 Azure 负载均衡器。 Azure 架构 在 Microsoft Azure 上部署任何基于Caché 的应用都需要特别注意某些方面。 本部分讨论通用的方面，对于您的应用的特定技术要求不做阐述。 本文档中提供了两个示例，一个基于_ InterSystems TrakCare 统一医疗信息系统，另一个基于完整的 InterSystems HealthShare 健康信息学平台部署，包括：_Information Exchange、Patient Index、Health Insight、Personal Community 和 Health Connect。 虚拟机 Azure 虚拟机 (VM) 分为两层：基本层和标准层。 两种类型提供对规模的选择。 基本层不提供标准层中的某些功能，例如负载均衡和自动伸缩。 因此，将标准层用于 TrakCare 部署。 标准层 VM 具有不同规模，按不同系列分组，即： A、D、DS、F、FS、G 和 GS。 DS、GS 和新的 FS 支持 Azure 高级存储的使用。 生产服务器通常需要使用高级存储来实现可靠性、低延迟和高性能。 因此，本文档中详细介绍的示例 TrakCare 和 HealthShare 部署架构将使用 FS、DS 或 GS 系列 VM。 注意，并非所有的虚拟机规模在所有区域中都可用。 有关虚拟机规模的详细信息，请参见： Windows 虚拟机规模 Linux 虚拟机规模 存储 TrakCare 和 HealthShare 服务器需要 Azure 高级存储。 高级存储将数据存储在固态硬盘 (SSD) 上，以低延迟提供高吞吐量；而标准存储将数据存储在硬盘驱动器 (HDD) 上，会导致性能的降低。 Azure 存储属于冗余且高度可用的系统，但是，请务必注意，可用性集合当前不提供跨存储故障域的冗余，在极少数情况下，这可能会导致问题。 Microsoft 有缓解方案，并正在努力使此过程对最终客户广泛可用且更容易使用。 建议您直接与当地的 Microsoft 团队合作以确定是否需要任何缓解方案。 当针对高级存储帐户配置磁盘时，IOPS 和吞吐量（带宽）取决于磁盘的大小。 当前，有三种类型的高级存储磁盘：P10、P20 和 P30。 每种对 IOPS 和吞吐量都有特定的限制，如下表所示。 高级磁盘类型 P4 P6 P10 P15 P20 P30 P40 P50 磁盘容量 32GB 64GB 128GB 256GB 512GB 1024GB 2048GB 4096GB 每个磁盘的 IOPS 120 240 500 1100 2300 5000 7500 7500 每个磁盘的吞吐量 25MB/s 50MB/s 100MB/s 125MB/s 150MB/s 200MB/s 250MB/s 250MB/s 注意：确保给定的 VM 上有足够的可用带宽来驱动磁盘流量。 例如，STANDARD_DS13 VM 具有每秒 256 MB 的专用带宽，可用于所有高级存储磁盘流量。 这意味着连接到该虚拟机的四个 P30 高级存储磁盘的吞吐量限制为每秒 256 MB，而不是四个 P30 磁盘理论上可以提供的每秒 800 MB 的速度。 有关高级存储磁盘的更多详细信息和限制，包括预配置的容量、性能、大小、IO 大小、缓存命中率、吞吐量目标和限制，请参阅： 高级存储 高可用性 InterSystems 建议在已定义的可用性集合中拥有两个或更多虚拟机。 之所以需要此配置，是因为在计划内或计划外的维护活动期间，至少有一个虚拟机可用于满足 99.95％ 的 Azure SLA。 这很重要，因为在数据中心更新期间，VM 会被并行关闭、升级并以不特定的顺序重新联机，导致应用程序在此维护窗口期不可用。 因此，高度可用的架构需要每种服务器至少部署两台，这些服务器包括负载均衡 Web 服务器、数据库镜像、多个应用程序服务器等。 有关 Azure 高可用性最佳做法的更多信息，请参见： 管理可用性 Web 服务器负载均衡 基于 Caché 的应用程序可能需要外部和内部负载均衡 Web 服务器。 外部负载均衡器用于通过 Internet 或 WAN（VPN 或 Express Route）进行的访问，而内部负载均衡器则通常用于内部流量。 Azure 负载均衡器是 4 层 (TCP, UDP) 的负载均衡器，可在负载均衡器集合中定义的云服务或虚拟机中的健康服务实例之间分配传入的流量。 Web 服务器负载均衡器必须配置客户端 IP 地址会话持续性（2 个元组）和可能的最短探测超时（当前为 5 秒）。 TrakCare 需要在用户登录期间保持会话持续性。 Microsoft 提供的下图显示了 ARM 部署模型中一个简单的 Azure 负载均衡器示例。 有关 Azure 负载均衡器的功能（例如分配算法、端口转发、服务监视、源 NAT ）和其他类型的可用负载均衡器的详细信息，请参阅： 负载均衡器概述 除了 Azure 外部负载均衡器，Azure 还提供 Azure 应用程序网关。 Application Gateway 是一个 L7 负载均衡器 (HTTP/HTPS)，支持基于 cookie 的会话相关性和 SSL 终端（SSL 卸载）。 SSL 卸载可减轻 Web 服务器的加密/解密开销，因为 SSL 连接会在负载均衡器处终止。 这种方法简化了管理，因为 SSL 证书是在网关中部署和管理，而不是在 Web 场中的所有节点上。 有关详细信息，请参阅︰ 应用程序网关概述 使用 Azure Resource Manager 为 SSL 卸载配置应用程序网关 数据库镜像 在 Azure 上部署基于 Caché 的应用程序时，要为 Caché 数据库服务器提供高可用性，需要使用同步数据库镜像，以在给定的主 Azure 区域中提供高可用性，并可能使用异步数据库镜像将数据复制到辅助 Azure 区域中的热备用数据库中，以根据您的运行时间服务水平协议要求来进行灾难恢复。 数据库镜像是两个数据库系统的逻辑分组，也就是所说的故障转移成员，它们在物理上是仅通过网络连接的独立系统。 在这两个系统之间进行仲裁后，镜像会自动将其中一个指定为主系统。 另一个自动成为备份系统。 外部客户端工作站或其他计算机通过镜像虚拟 IP (VIP) 连接到镜像，该虚拟 IP 在镜像配置期间指定。 镜像 VIP 会自动绑定到镜像主系统上的接口。 注意：在 Azure 中，无法配置镜像 VIP，因此已设计了替代解决方案。 当前，在 Azure 中部署数据库镜像时，建议在同一 Azure 可用性集中配置三个 VM（主 VM、备份 VM、仲裁器）。 这样可确保在任何给定的时间，Azure 都可以保证至少与其中两个 VM 以 99.95％ 的 SLA 建立外部连接，并且每个 VM 都位于不同的更新域和故障域中。 这样可以为数据库数据本身提供足够的隔离和冗余。 可在下列位置找到更多详细信息： Azure 可用性集 Azure 服务水平协议 (SLA) 包括 Azure 在内的任何 IaaS 云提供程序所面临的挑战，就是在没有虚拟 IP 功能的情况下，如何处理连接到应用程序的客户端的自动故障转移。 为了保持客户端连接的自动故障转移，已采取了两种策略。 首先，InterSystems 对 CSP 网关进行了增强，使其能够感知镜像，以此使得采用 CSP 网关的 Web 服务器到数据库服务器的连接不再需要 VIP。 CSP 网关将自动与两个镜像成员进行协商，并重定向到确定的主镜像成员。 如果使用 ECP 客户端，则将与其已经具备的镜像感知协同工作。 其次，CSP 网关和 ECP 客户端外部的连接仍然需要类 VIP 功能。 InterSystems 建议将轮询方法与_ mirror_status.cxw _运行状况检查状态页面介绍的内容结合使用，该页面在社区文章无虚拟 IP 地址的数据库镜像中进行了详细说明。 Azure 内部负载均衡器 (ILB) 将提供单一 IP 地址作为类 VIP 功能，将所有网络流量定向到主镜像成员。 ILB 只会将流量分配给主镜像成员。 此方法不会依赖轮询，且在镜像配置内的任何镜像成员成为主成员时，允许立即重定向。 在某些使用 Azure Traffic Manager 的灾难恢复方案中，可将此方法与轮询结合使用。 备份与恢复 备份操作有多个选项。 以下 3 个选项可供您通过 InterSystems 产品进行 Azure 部署。 下面的前 2 个选项采用快照类型的过程，该过程会在创建快照之前将数据库写入到磁盘的操作挂起，然后在快照成功后恢复更新。 可采取以下高级别步骤通过任一快照方法来创建洁净的备份： 通过数据库冻结 API 调用暂停对数据库的写入。 创建操作系统和数据磁盘的快照。 通过数据库解冻 API 调用恢复 Caché 写入。 将设施存档备份到备份位置 可以定期添加诸如完整性检查之类的其他步骤，以确保洁净且一致的备份。 决定使用哪种选项取决于您组织的运营要求和策略。 InterSystems 可与您详细讨论各种选项。 Azure 备份 如今，在 Azure ARM 平台中，使用 Azure Backup 和 Azure Automation Run Books 配合 InterSystems 外部冻结及解冻 API 功能，即可实现备份操作，从而实现真正的 24x7 全天候操作弹性并确保干净的常规备份。 有关管理和自动化 Azure 备份的详细信息，可在此处找到。 逻辑卷管理器快照 或者，可以在 VM 本身中部署单个备份代理，利用文件级备份，并结合逻辑卷管理器 (LVM) 快照，来使用市面上的许多第三方备份工具。 该模型的主要优点之一是能够对基于 Windows 或 Linux 的 VM 进行文件级恢复。 此解决方案需要注意的几点是，由于 Azure 和大多数其他 IaaS 云提供商都不提供磁带媒体，因此所有的备份存储库对于短期归档均基于磁盘，并利用 Blob 或存储桶类型的低成本存储来进行长期保留 (LTR)。 强烈建议您使用此方法来使用支持重复数据删除技术的备份产品，以最有效地利用基于磁盘的备份存储库。 这些具有云支持的备份产品的示例包括但不限于：Commvault、EMC Networker、HPE Data Protector 和 Veritas Netbackup。 InterSystems 不会验证或认可一种备份产品是否优于其他产品。 Caché 在线备份 对于小型部署，内置 Caché 在线备份工具也是可行的选择。 该 InterSystems 数据库在线备份实用工具通过捕获数据库中的所有块来备份数据库文件中的数据，然后将输出写入顺序文件。 这种专有的备份机制旨在使生产系统的用户不停机。 在 Azure 中，在线备份完成后，必须将备份输出文件和系统正在使用的所有其他文件复制到 Azure 文件共享中。 该过程需要在虚拟机中编写脚本并执行。 Azure 文件共享应使用 Azure RA-GRS 存储帐户以实现最大可用性。 注意，Azure 文件共享的最大共享大小为 5TB，最大文件大小为 1TB，每个共享（所有客户端共享）的最大吞吐量为 60 MB/s。 在线备份是入门级方法，适合于希望实施低成本备份解决方案的小型站点。 但是，随着数据库的增大，建议将使用快照技术的外部备份作为最佳做法，因为其具有以下优势：备份外部文件、更快的恢复时间，以及企业范围的数据和管理工具。 灾难恢复 在 Azure 上部署基于 Caché 的应用程序时，建议将包括网络、服务器和存储在内的灾难恢复 (DR) 资源放置在不同的 Azure 区域中。 指定的 DR Azure 区域所需的容量取决于您组织的需求。 在大多数情况下，以 DR 模式运行时需要 100％ 的生产能力，但是，在需要更多的生产能力作为弹性模型之前，可以配置较小的生产能力。 异步数据库镜像用于连续复制到 DR Azure 区域的虚拟机。 镜像使用数据库事务日志在 TCP/IP 网络上复制更新，其采用对主系统性能影响最小的方式。 强烈建议对这些 DR 异步镜像成员配置压缩和加密。 互联网上希望访问应用程序的所有外部客户端都将通过 Azure Traffic Manager 作为 DNS 服务进行路由。 Microsoft Azure Traffic Manager（ATM）用作交换机，负责将流量定向到当前活动的数据中心。 Azure Traffic Manager 支持多种算法来确定如何将最终用户路由到各个服务端点。 有关各种算法的详细信息，可在此处找到。 本文档中，“优先级”流量路由方法将与 Traffic Manager 端点监视和故障转移结合使用。 有关端点监视和故障转移的详细信息，可在此处找到。 Traffic Manager 的工作是向每个端点发出常规请求，然后验证响应。 如果端点未提供有效的响应，则 Traffic Manager 会将其状态显示为“降级”。 它将不会再被包含在 DNS 响应中，而是会返回一个备用的可用端点。 通过这种方式，将用户流量从失败的端点定向到可用端点。 使用上述方法，只有特定区域和特定镜像成员才允许流量通过。 这由端点定义控制，可从 InterSystems CSP 网关的 mirror_status 页面设置端点定义。 只有主镜像成员才能通过监控器探测来报告 HTTP 200 为“成功”。 Microsoft 提供的下图在高级别上显示了优先级流量例程算法。 Azure Traffic Manager 会产生一个所有客户端都可以连接到的端点，例如：“ https://my-app.trafficmanager.net ”。 此外，可以配置 A 记录来提供虚 URL，例如“ https://www.my-app-domain.com ”。Azure Traffic Manager 必须配置一个包含两个区域端点地址的配置文件。 在任何给定时间，只有其中的一个区域会根据端点监视在线报告。 这样可以确保流量在给定的时间仅流向一个区域。 区域之间的故障转移无需其他步骤，因为端点监控将检测到主 Azure 区域中的应用程序已关闭，并且该应用程序现在位于辅助 Azure 区域中。 这是因为 DR 异步镜像成员被提升为主成员，然后允许 CSP 网关将 HTTP 200 报告给 Traffic Manager 端点监视。 上述解决方案有很多替代方案，可以根据您组织的运营要求和服务水平协议进行自定义。 网络连接 根据您应用程序的连接要求，有多种连接模型可用：使用 Internet、IPSEC VPN 的连接模型，或使用 Azure Express Route 的专用链接。 选择方法取决于应用程序和用户需求。 三种方法的带宽使用情况各不相同，最好与您的 Azure 代表或 Azure 门户联系以确认给定区域的可用连接选项。 如果您正在使用 Express Route，则可为灾难恢复方案启用包括多线路和多区域访问在内的多个选项。 与 Express Route 提供商合作以了解他们支持的高可用性和灾难恢复方案至关重要。 安全 决定在公共云提供程序中部署应用程序时需要格外小心。 应遵循您组织的标准安全策略或专门为云开发的新安全策略，以维护您组织的安全合规性。 就客户端数据中心之外的数据以及物理安全控制方面，云部署的风险逐渐加大。 强烈建议对静态数据（数据库和日志）及飞行数据（网络通信）使用 InterSystems 数据库和日志加密，分别使用 AES 和 SSL/TLS 加密。 与所有加密密钥管理一样，您需要按照您组织的政策记录并遵循正确的程序，以确保数据安全，防止不必要的数据访问或安全漏洞。 当允许通过互联网进行访问时，可能需要第三方防火墙设备来实现其他功能，例如入侵检测、拒绝服务保护等。 架构图示例 下图说明了典型的 Caché 安装，其以数据库镜像（同步故障转移和 DR 异步）、使用 ECP 的应用程序服务器，以及多个负载均衡 Web 服务器的方式提供高可用性。 TrakCare 示例 下图说明了典型的 TrakCare 部署，其中包含多个负载均衡 Web 服务器，两个作为 ECP 客户端的 EPS 打印服务器，以及数据库镜像配置。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 ECP 客户端和 CSP 网关可感知镜像，不需要 VIP。 下图中的示例参考架构包括活动或主区域中的高可用性，可在主 Azure 区域不可用的情况下，执行灾难恢复到另一个 Azure 区域。 同样，在此示例中，数据库镜像包含 TrakCare DB、TrakCare Analytics 和 Integration 命名空间，这些都在一个镜像集群中。 TrakCare Azure 参考架构图 - 物理架构 另外，下图显示了该架构的逻辑图，包含架构所安装的相关高级软件产品及其功能用途。 TrakCare Azure 参考架构图 - 逻辑架构 HealthShare 示例 下图显示了一个典型的 HealthShare 部署，其具有多个负载均衡 Web 服务器，以及多个 HealthShare 产品，包括 Information Exchange、Patient Index、Personal Community、Health Insight 和 Health Connect。 这些产品中的每一个都包含一对数据库镜像，以在 Azure 可用性集合中提供高可用性。 虚拟 IP 地址仅用于与 ECP 或 CSP 网关不关联的连接。 HealthShare 产品之间用于 Web 服务通信的 CSP 网关可感知镜像，不需要 VIP。 下图中的示例参考架构包括活动或主区域中的高可用性，可在主 Azure 区域不可用的情况下，执行灾难恢复到另一个 Azure 区域。 HealthShare Azure 参考架构图 - 物理架构 另外，下图显示了该架构的逻辑图，包含架构所安装的相关高级软件产品、连接要求、方法及相应的功能用途。 HealthShare Azure 参考架构图 - 逻辑架构

本文以及后面两篇该系列文章，是为需要在其基于 InterSystems 产品的应用程序中使用 OAuth 2.0 框架（下文简称为 OAUTH）的开发人员或系统管理员提供的指南。 作者：InterSystems 高级销售工程师 Daniel Kutac # 发布后校正和更改历史记录 * 2016 年 8 月 3 日 - 修正了 Google 客户端配置屏幕截图，更新了 Google API 屏幕截图以反映新版本的页面 * 2016 年 8 月 28 日 - 更改了 JSON 相关代码，反映了对 Cache 2016.2 JSON 支持的更改 * 2017 年 5 月 3 日 - 更新了文本和屏幕，以反映 Cache 2017.1 的新 UI 和功能 * 2018 年 2 月 19 日 - 将 Caché 更改为 InterSystems IRIS 以反映最新的发展。 但是请记住，尽管产品名称发生更改，但**文章涵盖所有的 InterSystems 产品**——InterSystems IRIS 数据平台、Ensemble 和 Caché。 * 2020 年 8 月 17 日 - 大面积更改，软件方面更改更大。 要获取 Google 的更新版 Oauth2 的网址，请咨询 Micholai Mitchko。 _第 1 部分 客户端_ # **简介** 有关开放式授权框架 InterSystems 实现的相关内容，我们分 3 部分讲述，这是第 1 部分。 在第 1 部分中，我们对该主题进行了简短介绍，并提供了一个 InterSystems IRIS 应用程序担当授权服务器客户端并请求一些受保护资源的简单方案。 第 2 部分将讲述一个复杂一些的方案，在该方案中 InterSystems IRIS 本身通过 OpenID Connect 担当授权服务器和身份验证服务器。 本系列的最后一部分将描述 OAUTH 框架类的各个部分，它们由 InterSystems IRIS 实现。 ## **什么是开放授权框架 [1] ** 许多人已经听说过有关开放授权框架及其用途的信息。 因此这里只做简单介绍，以备未听说过的人参考。 开放授权框架 (OAUTH) 当前为 2.0 版，其是一种协议，允许基于 Web 的主应用程序通过在客户端（应用程序请求数据）和资源所有者（应用程序保存请求的数据）之间建立间接信任来以安全的方式交换信息。 信任本身由客户端和资源服务器都认可并信任的主体提供。 该主体称为授权服务器。 简单举例如下： 假设 Jenny（使用 OAUTH 术语，就是资源所有者）在开展 JennyCorp 公司的一个工作项目。 她为一个潜在的大型业务创建了项目计划，并邀请 JohnInc 公司的业务伙伴 John（客户端用户）审阅此文档。 不过，她并不愿意让 John 访问自己公司的 VPN，因此她将文档放在 Google 云端硬盘（资源服务器）或其他类似的云存储中。 她这样做，已经在她和 Google（授权服务器）之间建立了信任。 她标记了要与 John 共享的文档（John 已经使用 Google 云端硬盘服务，Jenny 知道他的电子邮件）。 当 John 想要阅读该文档时，他进行了 Google 帐户身份验证，然后通过移动设备（平板电脑、笔记本电脑等）启动文档编辑器（客户端服务器）并加载 Jenny 的项目文件。 这听起来很简单，但是两个人与 Google 之间有很多通信。 所有交流均遵循 OAuth 2.0 规范，因此 John 的客户端（阅读器应用程序）必须首先向 Google 进行身份验证（OAUTH 不涵盖此步骤），然后 John 申请获取 Google 对提供表格的同意，经过授权后，Google 就会发出一个访问令牌，授权阅读器应用程序访问文档。 阅读器应用程序使用该访问令牌向 Google 云端硬盘服务发出请求，以检索 Jenny 的文件。 下图说明了各方之间的通信  请注意：虽然所有的 OAUTH 2.0 通信都使用 HTTP 请求，但服务器不必非得是 Web 应用程序。 让我们通过 InterSystems IRIS 来说明这一简单方案。 # **简单 Google 云端硬盘演示** 在本演示中，我们将创建一个基于 CSP 的小型应用程序，该应用程序将使用我们自己的帐户（以及作为奖励的日历列表）来请求存储在 Google 云端硬盘服务中的资源（文件列表）。 ## **基本要求** 开始应用程序编码之前，我们需要准备环境。 这包括启用 SSL 的 Web 服务器和 Google 配置文件。 ### **Web 服务器配置** 如上所述，我们需要使用 SSL 与授权服务器进行通信，因为默认情况下 OAuth 2.0 要求如此。 我们需要确保数据安全，对吧？ 解释如何配置 Web 服务器来支持 SSL 的内容超出了本文讨论的范围，因此，请以您喜欢的方式参阅相应 Web 服务器的用户手册。 为了您的好奇心（我们稍后可能会显示一些屏幕截图），在此特定示例中，我们将使用 Microsoft IIS 服务器。 ### **Google 配置** 为了向 Google 注册，我们需要使用 Google API Manager-[ https://console.developers.google.com/apis/library?project=globalsummit2016demo ](https://console.developers.google.com/apis/library?project=globalsummit2016demo) 为了进行演示，我们创建了一个帐户 GlobalSummit2016Demo。 确保我们已启用 Drive API  现在，该定义凭据了  请注意以下事项： _Authorized JavaScript – _我们仅允许本地生成的脚本（相对于调用页面） _Authorized redirect URIs – 从理论上讲，我们可以将客户端应用程序重定向到任何站点，但是当使用 InterSystems IRIS OAUTH 实现时，我们必须重定向到** https://localhost/csp/sys/oauth2/OAuth2.Response.cls**。您可以定义多个授权的重定向 URI，如屏幕截图所示，但是对于本演示，我们只需要两者中的第二个条目。 最后，我们需要将 InterSystems IRIS 配置为 Google 授权服务器的客户端 ### **Caché /IRIS配置** InterSystems IRIS OAUTH2 客户端配置需要两步。 首先，我们需要创建服务器配置。 在 SMP 中，导航至**系统管理 > 安全性 > OAuth 2.0 > 客户端配置**。 点击**创建服务器配置**按钮，填写表格并保存。  输入到表格的所有信息可以在 Google 开发者控制台网站上找到。 请注意，InterSystems IRIS 支持自动 Open ID 发现。 但是，由于我们没有使用它，因此我们手动输入所有信息 现在，点击新创建的 Issuer Endpoint 旁边的“客户端配置”链接。并点击**创建客户端配置**按钮。  将“客户端信息”和“JWT 设置”选项卡保留为空（默认值），并填写客户端凭据。  请注意：我们正在创建机密客户端（这比公共客户端更安全，这意味着客户端秘密永远不会离开客户端服务器应用程序（永远不会传输到浏览器） 此外，请确保选中**“使用 SSL/TLS**”，并提供主机名（本地主机，因为我们将本地重定向到客户端应用程序），最后提供端口和前缀（当同一台机器上有多个 InterSystems IRIS 实例时，这非常有用）。 根据输入的信息，会计算客户端重定向 URL 并显示在上一行中。 在上面的屏幕截图中，我们提供了一个名为 GOOGLE 的 SSL 配置。 该名称本身实际上仅用于帮助您确定此特定通信通道使用的可能是众多 SSL 配置中的哪个。 Caché 使用 SSL/TLS 配置存储所有必要的信息，以建立与服务器（在本例中，为 Google OAuth 2.0 URI）的安全流量。 有关详细信息，请参阅[文档](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_aboutconfigs) 。 Supply Client ID 和 Client Secret 值从 Google 凭据定义表中获得（使用手动配置时）。 现在，我们完成了所有的配置步骤，可以开始编写 CSP 应用程序代码。 ## **客户端应用程序** 客户端应用程序是基于 Web 的简单 CSP 应用程序。 因此，它包含由 Web 服务器定义和执行的服务器端源代码，以及由 Web 浏览器向用户公开的用户界面。 下文提供的示例代码期望客户端应用程序在 GOOGLE 名称空间中运行。 请将路径 /csp/google/ 修改为您的命名空间。 ## **客户端服务器** 客户端服务器是一个简单的两页应用程序。 在该应用程序内，我们将： ·        将 URL 重定向到 Google 授权服务器 ·        执行向 Google Drive API 和 Google Calendar API 的请求并显示结果 ### **第 1 页** 这是应用程序的一页，我们决定在此处调用 Google 的资源。 以下是此页面上简单但功能齐全的代码。 Class Web.OAUTH2.Google1N Extends %CSP.Page { Parameter OAUTH2CLIENTREDIRECTURI = "https://localhost/csp/google/Web.OAUTH2.Google2N.cls"; Parameter OAUTH2APPNAME = "Google"; ClassMethod OnPage() As %Status { &html // we need to supply openid scope to authenticate to Google set scope="openid https://www.googleapis.com/auth/userinfo.email "_ "https://www.googleapis.com/auth/userinfo.profile "_ "https://www.googleapis.com/auth/drive.metadata.readonly "_ "https://www.googleapis.com/auth/calendar.readonly" set properties("approval_prompt")="force" set properties("include_granted_scopes")="true" set url=##class(%SYS.OAuth2.Authorization).GetAuthorizationCodeEndpoint(..#OAUTH2APPNAME,scope, ..#OAUTH2CLIENTREDIRECTURI,.properties,.isAuthorized,.sc) w !,"" &html Quit $$$OK } ClassMethod OnPreHTTP() As %Boolean [ ServerOnly = 1 ] { #dim %response as %CSP.Response set scope="openid https://www.googleapis.com/auth/userinfo.email "_ "https://www.googleapis.com/auth/userinfo.profile "_ "https://www.googleapis.com/auth/drive.metadata.readonly "_ "https://www.googleapis.com/auth/calendar.readonly" if ##class(%SYS.OAuth2.AccessToken).IsAuthorized(..#OAUTH2APPNAME,,scope,.accessToken,.idtoken,.responseProperties,.error) { set %response.ServerSideRedirect="Web.OAUTH2.Google2N.cls" } quit 1 } } 代码的简要说明如下： 1.      OnPreHTTP 方法 - 首先，我们有机会时检查一下，我们是否由于 Google 授权而获得了有效的访问令牌——这种情况可能会发生，例如当我们只是刷新页面时。 如果没有，我们需要授权。 如果我们有令牌，我们只需将页面重定向到显示结果的页面 2.       OnPage 方法 - 只有在我们没有可用的有效访问令牌时，我们才到这里，因此我们需要开始通信——向 Google 进行身份验证和授权，以便它向我们授予访问令牌。 3.       我们定义了作用域字符串和属性数组，用于修改 Google 身份验证对话框的行为（我们需要先向 Google 进行身份验证，然后它才能根据我们的身份对我们进行授权）。 4.       最后，我们收到 Google 登录页面的 URL，然后将其提供给用户，接着提供同意页面。 还有一点注意事项： 我们在 OAUTH2CLIENTREDIRECTURI 参数的 中指定真正的重定向页面。 但是，我们在 Google 凭据定义中使用了 InterSystems IRIS OAUTH 框架的系统页面！ 重定向由我们的 OAUTH 处理程序类在内部处理。 ### **第 2 页** 此页面显示 Google 授权的结果，如果成功，我们将调用 Google API 调用以检索数据。 同样，此代码简单，但功能齐全。 相比读者的想象，我们以更结构化的方式来显示输入数据。 Include %occInclude Class Web.OAUTH2.Google2N Extends %CSP.Page { Parameter OAUTH2APPNAME = "Google"; Parameter OAUTH2ROOT = "https://www.googleapis.com"; ClassMethod OnPage() As %Status { &html // Check if we have an access token set scope="openid https://www.googleapis.com/auth/userinfo.email "_ "https://www.googleapis.com/auth/userinfo.profile "_ "https://www.googleapis.com/auth/drive.metadata.readonly "_ "https://www.googleapis.com/auth/calendar.readonly" set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(..#OAUTH2APPNAME,,scope,.accessToken,.idtoken,.responseProperties,.error) if isAuthorized { // Google has no introspection endpoint - nothing to call - the introspection endpoint and display result -- see RFC 7662. w "Data from GetUserInfo API" // userinfo has special API, but could be also retrieved by just calling Get() method with appropriate url try { set tHttpRequest=##class(%Net.HttpRequest).%New() $$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).AddAccessToken(tHttpRequest,"query","GOOGLE",..#OAUTH2APPNAME)) $$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).GetUserinfo(..#OAUTH2APPNAME,accessToken,,.jsonObject)) w jsonObject.%ToJSON() } catch (e) { w "ERROR: ",$zcvt(e.DisplayString(),"O","HTML")_"" } /****************************************** * * * Retrieve info from other APIs * * * ******************************************/ w "" do ..RetrieveAPIInfo("/drive/v3/files") do ..RetrieveAPIInfo("/calendar/v3/users/me/calendarList") } else { w "Not authorized!" } &html Quit $$$OK } ClassMethod RetrieveAPIInfo(api As %String) { w "Data from "_api_"" try { set tHttpRequest=##class(%Net.HttpRequest).%New() $$$THROWONERROR(sc,##class(%SYS.OAuth2.AccessToken).AddAccessToken(tHttpRequest,"query","GOOGLE",..#OAUTH2APPNAME)) $$$THROWONERROR(sc,tHttpRequest.Get(..#OAUTH2ROOT_api)) set tHttpResponse=tHttpRequest.HttpResponse s tJSONString=tHttpResponse.Data.Read() if $e(tJSONString)'="{" { // not a JSON d tHttpResponse.OutputToDevice() } else { w tJSONString w "" /* // new JSON API &html s tJSONObject={}.%FromJSON(tJSONString) set iterator=tJSONObject.%GetIterator() while iterator.%GetNext(.key,.value) { if $isobject(value) { set iterator1=value.%GetIterator() w "",key,"" while iterator1.%GetNext(.key1,.value1) { if $isobject(value1) { set iterator2=value1.%GetIterator() w "",key1,"" while iterator2.%GetNext(.key2,.value2) { write !, "",key2, "",value2,"" } // this way we can go on and on into the embedded objects/arrays w "" } else { write !, "",key1, "",value1,"" } } w "" } else { write !, "",key, "",value,"" } } &html */ } } catch (e) { w "ERROR: ",$zcvt(e.DisplayString(),"O","HTML")_"" } } }     让我们快速看一下代码： 1.       首先，我们需要检查一下我们是否具有有效的访问令牌（即我们是否被授权） 2.       如果是，我们可以向 Google 提供且由已发布访问令牌覆盖的 API 发出请求 3.       为此，我们使用标准的 ％Net.HttpRequest 类，但根据 API 规范，我们将访问令牌添加到 GET 或 POST 方法中 4.       如您所见，为了方便您，OAUTH 框架已实现 GetUserInfo（）方法，但是您可以使用 Google API 规范直接检索用户信息，就像我们在 RetrieveAPIInfo（）助手方法中所做的一样。 5.       由于在 OAUTH 世界中以 JSON 格式交换数据司空见惯，因此我们只读取传入的数据，然后简单地将其转储到浏览器。 应用程序开发人员可以解析和格式化接收到的数据，以便用户可以看明白。 但这超出了本演示的范围。 （尽管一些代码有注释，显示了如何完成解析。） 下图是一个输出屏幕截图，显示了原始 JSON 数据。  继续阅读[第 2 部分](https://community.intersystems.com/post/cach%C3%A9-open-authorization-framework-oauth-20-implementation-part-2)，该部分讲述 InterSystems IRIS 担当授权服务器和 OpenID Connect 提供程序相关的内容。   [1] https://tools.ietf.org/html/rfc6749, https://tools.ietf.org/html/rfc6750

亲爱的社区开发者们， InterSystems 编程大奖赛 圆满结束！这是一场令人难以置信的竞赛，参与的应用程序和开发者数量创下了记录! 谢谢大家的参与！现在是时候宣布获奖者了！ 让我们把掌声送给这些开发者们！ 🏆 专家提名奖（Experts Nomination）- 获奖者由我们特别挑选的专家团选出： 🥇 第一名，奖金 $6,000 获奖项目 e-intersystems-iris @Dmitry.Maslennikov 🥈 第二名，奖金 $3,000 获奖项目 iris-rad-studio @Henrique.GonçalvesDias 🥉 第三名，奖金 $2,000 获奖项目 HealthInfoQueryLayer @Botai.Zhang 🏆 社区提名奖（Community Nomination） - 获得总投票数最多的应用： 🥇 第一名，奖金 $3,000 获奖项目 HealthInfoQueryLayer @Botai.Zhang 🥈 第二名，奖金 $1,500 获奖项目 Dictionary comparison scheme of cache database @Weiwei.Yang 🥉 第三名，奖金 $500 获奖项目 vscode-intersystems-iris @Dmitry.Maslennikov 恭喜所有获奖者和参赛者！ 感谢大家对本次大赛的关注和在本次大赛中付出的努力! 恭喜中国获奖者 @Botai.Zhang @Weiwei.Yang ! 感谢 @jingqi.LIu @Deming.xu 的参与！ 期待其他开发者更多的作品！ 非常荣幸参与其中，对所有的开发者来说，很棒的平台！