当我们还沉浸在OpenAI 宫斗剧时，亚马逊云科技可没功夫闲着，就在一天前，他们推出 Amazon Q 生成式人工智能聊天机器人。

如果说ChatGPT 面向的是大众消费者，那么 Amazon Q 这是一款专门为企业量身定制的生成式人工智能聊天机器人。

在2023 re:Invent全球大会上，亚马逊云科技首次推出了名为「Amazon Q」生成式AI助手——专为企业用户量身定制——在满足业务严苛需求的同时，保证信息的安全可控。

企业的 IT 专业人员和开发人员可以使用 Amazon Q 进行研究、编写新功能、排除错误以及在亚马逊云服务器上构建应用程序。

除此之外，大会还在芯片、AI平台等多个领域扔出了生成式AI年终王炸。

值得一提的是， Q这个名字来源于「问题」（question），同时也是对007系列中的天才角色，以及「星际迷航」中的强大种族的致敬

如今，大模型的竞争已经来到下半场，在这个全新的时代，亚马逊云科技也开创了属于企业级生成式AI的全新范式，帮助他们在各自的领域创造「颠覆格局」的AI产品。

Amazon Q：定制AI助手、专精企业数据

作为本届re: Invent上备受期待的发布，全新的生成式AI助手Amazon Q可以说完全是为客户的业务需求量身定制的。

基于亚马逊云科技17年的知识积累，Amazon Q不仅会向用户提供多个潜在的解决方案，还会解释清楚为什么会提出这样的建议。

根据亚马逊云科技CEO Adam Selipsky的介绍，Amazon Q可以和我们聊天、生成内容，还能采取行动。如何使用它，取决于我们对系统、数据存储库和运营的理解。

打破数据业务屏障，全面互联互通

对企业来说，Amanzon Q对于信息管理和工作流的重构，都有着重大意义。

很多企业都面临着这样的痛点——

虽然企业掌握着分布在多个文档、系统和应用程序中的大量信息，但是从财务、人力资源，到营销和销售，每个组织的员工在日常工作中都会都耗费大量时间搜索内部信息源、拼凑分析结果、写报告、做PPT，还得针对不同受众调整内容。

而目前市面上的通用解决方案，并未与内部资源相连，也不了解使用者的身份、角色和权限，无法确定员工在工作中应该访问哪些资源。公开的解决方案，可能会使用数据输入和输出进行训练，存在安全和隐私风险。

即使有一些生成式AI方案，但它们只能在特定工具内工作，不能扩展到企业的所有系统和应用中，限制了员工充分利用AI的潜力。

使用Amazon Q，我们可以把它与公司的业务数据、信息、系统连接起来，它就可以综合所有信息，提供量身定做的解决方案。

它内置了40多个常用的数据源连接器，包括Amazon S3、Dropbox、Confluence、Google Drive、Microsoft 365、Salesforce、ServiceNow和Zendesk，还能为内部Intranets、wiki、run books等建立自定义连接器。

当Amazon Q综合了所有信息，我们就可以部署自己的智能助手了。它会生成一个Web应用，让员工使用身份验证系统来访问程序。

智能助手自己造

自定义配置完成后，Amazon Q会索引到所有它连接是数据和内容，学习企业知识，包括组织结构、核心概念和产品名称。

所有使用Amazon Q的客户，都可以选择最适合自己的模型，连接到模型的Bedrock API上，然后使用模型来了解数据、策略和工作流程，最后完成Amazon Q的部署。

然后，员工就可以让Amazon Q来完成总结或生成文章、撰写邮件，以及创建服务工单、创建会议议程、给团队发通知等等的工作了。甚至，还可以上传word、PDF、Excel，来提问文件中的问题。

此外，如果问题涉及到多个数据来源，Amazon Q会综合相关内容，在给出答案的同时，附上参考链接。

两天升完1000款应用

亚马逊云科技内部的一支团队完成了一项创举：短短两天内，就在Amazon Q的加持下，将上千款应用程序从Java 8升级到了Java 17。

这种奇迹般的神速，靠是就是Amanzon Q的代码转换功能。

具体来说，亚马逊云科技的CodeWhisperer，可以生成和解释代码。结合此功能，在受支持的IDE（如CodeCatalyst），Amazon Q可以根据客户代码的知识生成测试，从而完成对软件的基准测试。

它还可以在软件中实现新功能，转换代码，升级代码包、存储库和框架，而这些，都可以用自然语言完成。

因为对亚马逊云科技，以及它提供的产品和服务有透彻的了解，Amazon Q可以理解应用程序工作负载之间的细微差别。

如果你问它，关于高性能视频编解码程序的最佳EC4实例，Amazon Q会给出一个列表，综合考虑从性能到成本的各个因素。

Selipsky表示，Amazon Q具有革命性的意义，从事各种类型工作的人，都将从中受益。

破除幻觉，保障安全

针对生成式AI系统普遍面临的幻觉问题，Amazon Q是怎样解决的呢？

为了减轻幻觉，管理员可以选择让Amazon Q仅从公司文档中提取知识，而不是从基础模型中。

Amazon Q给出的答案、采取的行动，也都是完全可控、可过滤的。

它提供的答案和间接，会严格忠实于客户提供的源材料和知识。而且，它只会返回用户有权查看的信息，管理员也可以限制敏感主题，让它过滤掉不适当的问题和答案。

比如，可以把Amazon Q设置为只回答安全团队提出的安全相关问题，或从公司内部目录中，提取与人员有关问题的答案。

而且，客户的数据也是绝对安全的。驱动Amazon Q的模板包括Bedrock平台中的模型，以及亚马逊云科技自己的Titan系列，这些模型都不会用客户的数据进行训练。

因此，出于安全原因对生成式AI持谨慎态度的公司，可以放心使用Amazon Q。

Amazon Bedrock重磅升级：全新模型、自动解决「选择困难症」

今年4月，亚马逊云科技首次官宣Amazon Bedrock，一个能够提供基础模型的服务平台。

这一平台最大的特色，就是让开发者能够轻松定制模型，并松构建属于自己的生成式AI应用程序。

从发布至今，Amazon Bedrock已经集成了大量的第三方模型，以及亚马逊自研的Titan模型。

这次，Amazon Bedrock再次迎来了升级。

在自研基础模型方面，亚马逊云科技全新推出文生图模型Amazon Titan Image Generator。与此同时，还发布了两个关注文本处理任务的模型Amazon Titan Text Lite和Amazon Titan Text Express。

此外，全新升级第三方模型Claude 2.1，Stability Diffusion XL 1.0、Llama 2-70B也加入了Amazon Bedrock。

AI生图模型登场，还可添加隐形水印

当前，AI生图已经进入白热化阶段，DALL·E 3、Stable Diffusion、Midjourney等AI工具在业界引起巨大的反响。

同样，亚马逊云科技也加入了这场大战。

re:Invent大会上，全新的Amazon Titan Image Generator只需要一个指令，能够生成各种逼真的图像。

比如，你可以让它生成一张雪景中的木屋，甚至还可以动嘴更改主题、背景等。

再比如，当你想要一个背包的时候，你可以让Amazon Titan Image Generator为你搜索相关图片，并做出推荐。

最令人惊艳的是，当你选好其中一个书包，但又不知道在不同场景中的效果如何。

这时，你就可以让AI生图工具，为你「想象」，也就是我们常见的「图像扩展」能力。

深蓝色帆布包，放在在下雪天中，已经在教室中，给人的感受更加直观了。

Amazon Titan Image Generator是在广泛的领域的各种数据集上完成训练，可以选择在自定义数据集上进行微调。

对此，开发人员还可以在此基础上构建自己的图像生成器，由Amazon Bedrock上的模型提供支持。

Amazon Titan Image Generator生成的所有图像都包含了隐形水印，不会干扰图像的视觉效果，没有延迟，并且不会被裁剪或压缩。

而且，水印并不局限于文件的元数据。

对于如何检测不可见的水印，亚马逊云科技还创建了一个API，输入图像便可以看见图像来源。

亚马逊云科技进军AI图像生成领域，标志着该公司人工智能战略进入了一个新阶段。

Amazon Titan Image Generator未来可能被证明是AI驱动内容创作中，新应用的催化剂。

通过提供强大的工具和法律保障，亚马逊云科技有望在人工智能图像生成领域留下浓墨重彩的一笔。

文本模型同步上新

除了Amazon Titan Image Generator，大会上，亚马逊云科技还更新了两个文本生成的模型。

一个是Amazon Titan Text Lite，用于文案写作等基本任务，结构紧凑非常适合微调。

另一个是用于对话聊天的应用程序Amazon Titan Text Express，专为较大的任务而设计，并且同时兼顾了价格和性能。

终结大模型「选择困难症」

然而，没有哪一个模型是可以完美适应所有应用场景的。不同的模型在能力、价格和性能上也各有千秋。

在选择对比的过程中，企业首先需要花费数天时间来确定评价基准、配置测试工具，然后才能进行实际的评估。

这不仅需要深厚的专业知识，而且由于现有的测试并不适合一些主观标准的评估（如相关性和风格），企业也因此不得不引入人工审查来进行判断。

如此繁琐且耗时的流程，极大地限制了企业利用生成式AI的潜力，尤其是对于需求场景复杂多样的客户来说。

针对这一问题，亚马逊云科技在Amazon Bedrock平台上全新发布的Model Evaluation，能够帮助客户评估AI模型的能力。

模型评估有两个组成部分：自动评估和人工评估。

在自动化评估中，开发人员可以进入Amazon Bedrock控制台，选择要评估的模型。如Llama 2、Claude 2和Stable Diffusion等等，都可以进行选择。

然后，他们可以评估模型在摘要总结、文本分类、问答和文本生成等任务的稳健性、准确性或安全性等指标上的性能。

评估过程中，亚马逊云科技会提供测试数据集，不过，客户可以把自己的数据引入基准测试平台，以便选择更适合自身业务场景的模型。

对于人工评估来说，客户可以选择与亚马逊云科技评估团队合作，或与自己的团队合作。

然后，客户提供指定的任务类型（比如摘要或文本生成）、评估指标以及要使用的数据集，并会得到定制的定价和时间表。

四大重构，让生成式AI更普惠

生成式AI大红大紫当下，每家企业，每个开发者都有机会，创造出时代爆款应用。

Andy Jessy曾经提过：任何人哪怕在自己的宿舍，或者车库里开始自己的创新之旅，也能获得与大型企业一样的基础设施和成本优势，来实现自己的创新。

值得一提的是，目前全球有80%的独角兽企业，都在使用亚马逊云科技的技术。

这次re:Invent大会上，这家科技巨头更是利用20多年在深度学习技术积淀，把自身产品进行了重构。

重构基础设施、重构存储、重构计算、还有重构生成式AI。

在重构生成式AI过程中，亚马逊云科技提供了个完整全链路工具栈，包括底层的基础设施，中间微调模型需求的工具服务，以及最上层应用层。

第一层「基础设施」，亚马逊云科技这次推出了第四代自研服务器CPU芯片Graviton4，比起第三代处理速度快30%。

还有专为生成式AI训练设计的云端AI芯片Trainium2，比上一代芯片性能提高4倍。

除此之外，亚马逊云科技还与英伟达合作推出带有32个GH200超级芯片的超算——NVIDIA GH200 NVL32，用于加速训练1万亿参数的AI大模型。

在第二层模型层中，亚马逊云科技提供了模型调用平台Amazon Bedrock、Amazon Bedrock Agent，以及云机器学习平台Amazon SageMaker等等。

在最上层应用层中，除了Amazon CodeWhisper、Amazon QuickSight，这次全新增加了Amazon Q人工智能助手。

很明显，亚马逊云科技凭借其独特的三层技术栈，能够为客户提供全面的工具链条，去打造符合自身业务场景的应用。

从 2006 年以来，亚马逊云科技一直是世界上最全面、应用最广泛的云。亚马逊云科技一直在不断扩展其服务，以支持几乎任何工作负载，现在拥有 240 多种功能齐全的服务，涉及计算、存储、数据库、网络、分析、机器学习和人工智能 (AI)、物联网 (IoT)、通过 32 个地理区域内的 102 个可用区进行移动、安全、混合、虚拟和增强现实（VR 和 AR）、媒体和应用程序开发、部署和管理。

参考资料：

https://press.aboutamazon.com/2023/11/aws-announces-amazon-q-to-reimagine-the-future-of-work

https://press.aboutamazon.com/2023/11/aws-announces-more-model-choice-and-powerful-new-capabilities-in-amazon-bedrock-to-securely-build-and-scale-generative-ai-applications

https://techcrunch.com/2023/11/29/heres-everything-aws-reinvent-2023-so-far/

立即点击“阅读原文”，查看2023亚马逊云科技 re:Invent更多相关内容。

2023年，生成式AI技术破茧成蝶，生成式AI能够自动生成数据或内容的人工智能，与仅仅基于输入数据进行分类或预测的判别式AI不同，生成式AI可以创造新的、未曾见过的输出。这类AI通常基于生成式模型，可以在多种任务中生成各种类型的数据，如文本、图像、音乐或视频等。

例如：

文本生成，像OpenAI的GPT–3就是一个能够生成连贯、有意义文本的模型。

图像生成，有些生成式模型可以创造全新的、逼真的图像，或是基于给定的草图生成完成的艺术作品。

音乐和声音生成：生成式AI也可以用于生成新的音乐作品或声音效果。

数据增强：在机器学习训练中，有时可用的数据量是有限的。生成式AI可以用来增加训练数据，从而改善模型的性能。

风格迁移：例如，可以将某种艺术风格应用于图像或视频，或将文本转化为特定的写作风格。

但同时，生成式AI又是一把双刃剑，它既可以帮助企业解决实际问题，又面临着数据泄露等巨大风险。今年年初，某大型全球化企业就在大模型训练过程中，泄露了企业数据库中的机密信息，给企业带来了巨大的负面影响。而此类事件依然层出不穷。生成式AI在训练与使用过程中，有诸多环节都将面临数据泄露风险，应该以何种方式保障安全呢？

8月31日，亚马逊云科技re:Inforce 2023中国站正式开启，此次大会以“AI时代 全面智能的安全”为主题，目标就是帮助企业解决生成式AI在全部流程环节中的安全挑战。

安全是构建生成式AI应用之根本

亚马逊云科技大中华区解决方案架构总监代闻表示：安全是构建生成式AI应用不可回避的重要议题。从全栈角度出发，应该从数据、传输、应用到基础设施整体构建出可靠的合规体系，这样才能真正保障AI应用的安全。

代闻

亚马逊云科技大中华区解决方案架构总监

亚马逊云科技一直严格遵从客户拥有和控制数据的理念，提供了行业领先的技术和物理措施来防止未经授权的访问，为数据提供涵盖存储、传输、使用、治理等各个环节的加密及保护服务。

举例而言，企业在训练AI模型过程中首先要访问数据库，现代企业的业务数据是创新的基础，也是“命脉”，一旦数据泄露就将带来不可逆的恶劣影响。同时，在数据传输、使用、治理、访问等各个环节，也会面临泄露风险。

因此，安全是构建生成式AI应用不可回避的议题！

针对生成式AI，亚马逊云科技将安全防护划分为三个阶段，分别为：数据和模型安全、应用安全和全球合规，并基于此提供了更为系统化的安全防护工具。

数据安全，从存储和传输开始

在数据保护方面，亚马逊云科技重点推荐的第一项服务就是Amazon KMS。其全称为Amazon Key Management Service，是一项通过硬件安全模块来保护用户密钥的云端安全服务。借助Amazon KMS，用户可以创建和管理加密密钥，并控制相关权限。这些密钥可用于跨各种亚马逊云科技服务和用户应用程序访问加密数据。

同样地，数据传输也是安全防护的重要阶段，此环节可通过Amazon Nitro来构建独立的安全传输通道。Amazon Nitro是一种虚拟化基础设施，Amazon Nitro安全芯片可用于加密和验证虚拟机的访问，并可检测未经授权的硬件修改和恶意软件的植入。依托于虚拟化技术，Amazon Nitro系统还能够提供更好的网络和存储性能。

有了安全的存储和传输，针对计算环节亚马逊云科技则有Amazon Nitro Enclaves计算加密。它可将计算实例进行隔离，并控制应用互访vCPU和内存，可帮助用户减少用于处理最敏感数据的应用程序的攻击面，从而保护计算安全。

涂鸦信息技术有限公司安全总监刘龙威表示：涂鸦智能是一家全球化的物联网解决方案商，以亚马逊云科技Amazon Nitro为安全的云基础，通过硬件隔离的方式保障了整个用户数据体系的可信。与Amazon KMS联动实现了更高基本的安全管理，从而服务于78万的开发者及海量的IoT设备，并使其牢不可破。

在re:Inforce 2023大会上，亚马逊云科技与涂鸦智能成立“联合安全实验室”，双方将在智能家居、数据安全、安全文化建设、海外合规等领域，重点就机密计算及数据隐私、Matter技术合作及体系建设、生成式AI在IoT领域等安全实践展开联合共创。

此外，亚马逊云科技中国方案开发中心还正式发布了敏感数据保护解决方案，可实现自动发现企业敏感数据，并在统一平台管理数据资产。例如在Amazon S3存储中，允许用户创建数据目录、使用内置或定制数据识别规则定义敏感数据类型，以机器学习方式来匹配并识别敏感信息，并做出警告。以可视化方式进行管理，进而帮助用户实现对敏感数据的管理与保护。目前该解决方案已经可以提供下载。

训练安全

Amazon SageMaker的模型三剑客

数据在存储、传输及计算环节的安全得到了保障，接下来需要关注的自然就是模型的构建环节了。

代闻表示：Amazon IAM API每秒调用次数超过10亿，其为大模型的构建提供了强大的源动力。Amazon SageMaker正在为设置、授权、验证、调优等环节提供针对模型的访问策略，并通过Amazon Model Cards、Amazon Model Monitor及Amazon Model Registry等工具全方位地监控模型的运行。

在AI大模型的初始爆发期，很多企业的模型训练环节都处于“裸奔”状态，即原始数据与模型未加防护，此时的数据泄露风险也是最高。

针对这些痛点，模型三剑客之一的Amazon SageMaker Model Cards问世了，它是一套文档化机器学习模型的规范格式工具，可实现对模型信息的统一管理，包括模型的描述、功能、性能等信息。通过使用Amazon Model Cards，用户可以更好地了解和评估机器学习模型，以选择最适合其需求的模型，并为下一步监测与管理做好准备。

Amazon SageMaker Model Monitor提供的就是自动化监控与检测服务，可以帮助用户在生产环境中监控模型的性能、数据质量和数据偏差，以确保模型的准确性和稳定性。

功能方面Amazon Model Monitor提供了数据捕获、数据分析、数据报告和数据警报，可生成详细的报告和警报通知用户，有利于促进模型的持续改进和优化。

Amazon Model Registry则是Amazon SageMaker提供的一个功能强大的工具，用于管理和跟踪机器学习模型的版本和元数据。它提供了版本控制、回滚、元数据管理和集成功能，使用户能够更好地管理和部署模型。

在Amazon SageMaker这三套工具的帮助下，能够让用户实现模型管理自动化，极大提升了工作效率。

大模型之潮已经势不可挡，如果企业级用户自身技术能力较弱，是否可以尝试构建大模型呢？

别急，这就安排！

就在今年4月，亚马逊云科技发布了完全托管的基础模型服务Amazon Bedrock，可让用户根据需求通过API访问及使用其中的基础模型。Amazon Bedrock可使用用户自己的数据私下自定义FM，并使用相关工具和功能将它们无缝集成和部署到应用程序中，无需管理任何基础设施。

举例而言，用户希望在零基础的情况下构建一套文本生成大模型，那么就可以通过简单的操作在亚马逊云端自定义出模型需求，并通过各种模型工具将其集成并部署到应用之中，就像拼装乐高一样简单，极大降低了模型构建的门槛。

开发安全，利用AI取长补短

度过了激动人心的模型构建环节，接下来是开发。很多企业级用户对开发戏称是：人多手杂，容易出错，同时还经常出现安全性问题。

针对这些痛点，亚马逊云科技展示了两套自动化工具服务，能够帮助用户排忧解难。

Amazon CodeWhisperer 可以看作是AI编程助手，经过数十亿行代码的训练，可以根据用户需求和现有代码实时生成从代码片段到全函数的代码建议。Amazon CodeWhisperer支持主流编程语言和IDE，还可以为用户提供有关 API 安全性、性能和最佳实践的建议。

融合机器学习和自动化分析就有了Amazon CodeGuru Security，它是一套强大的代码漏洞扫描工具，可提供漏洞修补建议，并解决检测配置错误、权限问题和敏感数据的泄露等安全问题。有效提升代码的安全性和可靠性。

 

运行安全，来自云端的保障

当生成式AI大模型经历开发后就迎来上线运行，而在该阶段的安全防护也不能掉以轻心。因为在实际操作过程中，有很多安全事件都出在运行环节。此时，应用程序需要保护模型本身、数据及用户隐私等来自多方面的安全，而最有效的方式就是：验证。

Amazon Verified Permissions是亚马逊云科技向开发者提供的一种验证用户访问权限的机制。通过该服务，开发者可以确保用户只能访问其应用程序需要的有效权限，以保护用户的隐私和数据安全。

当用户向应用程序授权时，亚马逊会验证并返回一个访问令牌，该令牌包含用户已授权的权限。开发者可以使用这个令牌来验证用户的权限，并根据需要执行相应的操作。

通过令牌式验证，开发者可以确保用户数据的安全性，并且遵守隐私法规和规定。同时也通过访问权限控制来保障应用程序的数据安全。

 

构建全球化安全合规

在全球安全合规方面，亚马逊云科技的全球化基础设施包括超过200大类广泛而深入的云服务和解决方案，包括覆盖全球的安全合规、高速稳定的云基础设施，以及来自亚马逊的全球资源和创新文化。

据了解，亚马逊云科技现已在全球获得超过140个安全标准和合规认证。并进一步通过在其500多项自身合规审计控制项中使用 AI 技术，大幅提升了自身的合规效率，将审计时间节约了53%。

此外，亚马逊云科技还通过零信任架构，来帮助用户增强安全性、灵活性、扩展性并有效降低来自安全方面的成本，帮助企业构建更安全、高效和可靠的云安全体系。

---

生成式AI为我们带来更多的创作、个性化服务、与用户的交互以及创新和研究的可能性。也为人类创造力和智慧的拓展提供了新的工具和平台。

在短短几个月的时间里，生成式AI在中国市场就掀起了一场全行业的“百模大战”，并将AI创新推向了一个新的高峰。诸多企业开始了探索与尝试，同时也迎来了更为复杂的安全性挑战。为了帮助企业迎接这日益复杂的安全挑战，亚马逊云科技通过技术积累、创新能力和对AI的深入理解，推出了多项面向生成式AI全流程的安全服务，着力帮助企业解决实际问题。

生产式AI的安全性式是一个多面且持续的挑战，确保这类AI工具不被用于或恶意目的、同时确保它们的输出可靠并不造成意外伤害至关重要的。

提高生成式AI的安全性是一项重要的任务，可以采取多种方法来降低潜在的风险。例如：改进训练数据的质量、监督和审核机制、对输出限制、反馈循环方面、以及道德框架和指导原则、法律和法规等等。

总之，提高生成式AI的安全性需要综合考虑技术、法律、伦理和社会因素。这是一个不断发展的领域，需要持续得努力来减少风险并确保AI系统对社会的积极影响。

安全之事无小事，关乎企业发展之命脉。此次大会亚马逊云科技携同合作伙伴一起，以客户为中心，通过安全服务深入到应用AI的每一个环节，共同构建起面向AI的未来安全。

数字经济时代以数字技术和互联网为基础，以数据为核心，具有智能化特征的一种新形态。

然而，不少企业发现自己面对的是一个充满挑战的局面：一方面是数据爆炸性增长带来的存储压力，根据IDC的预测，2025年全球数据总量将达到180ZB，是2018年（33ZB）的5.4倍；另一方面，数据安全也面临非常严峻的挑战，Gartner预测,到2025年75%的组织将面临一种或多种勒索软件的威胁。

面对数字化经济所带来的挑战，亚马逊云科技坚持创新，不断丰富存储服务的功能和类型，如亚马逊云科技的Amazon S3等，以及分布式文件系统，如Hadoop的HDFS等。同时在数据保护和合规上持续改进，以帮助客户更有效地构建起云上安全环境及满足合规要求，为其业务保驾护航。

丰富的存储服务，满足不同业务需求

众所周知，存储与计算、网络一起共同构成了传统数据中心的三大基础能力，在云时代同样如此，存储也是公有云的核心基础服务。

实际上，公有云市场大幕正是从云存储服务开启的。2006年3月14日亚马逊云科技推出了自己的第一项云服务Amazon S3，这也是世界上首个公有云的云存储服务。

如今，Amazon S3的服务类型已经达到8种，存储的对象数量超过230万亿个，平均每秒有超过1亿次请求。已经成为对象存储的事实标准。亚马逊云科技的存储服务也从最初的Amazon S3，扩展到包括块存储、文件存储、数据库服务等在内的多种数据存储服务。Amazon S3还是成百上千个数据湖的基础。

为了致敬Amazon S3，亚马逊云科技会在每年的3月14日这一天举办Pi day活动，纪念S3服务的诞生。这一天，亚马逊云科技的专家会在Twitch上举办长达4个小时的教学和培训，不仅有关于Amazon S3的最佳实践，还有Amazon在数据服务方面的最新创新。

除了不断丰富存储类型之外，亚马逊云一直通过创新降低数据的存储成本，其中的Amazon S3智能分层服务尤为值得一提。

一般而言，数据存储的费用与访问频度和性能相关，读得越频繁、读取性能要求越高，费用就越高。亚马逊云科技Amazon S3的不同存储服务分别对应不同的访问频度和不同性能要求，但客户有时候很难确定到底该选择哪一种（不知道或者难以预测）。Amazon S3智能分层就为解决这个问题推出的创新服务。

2018年推出的这项可根据访问频次自动将数据移动到最经济的访问层，在保证性能的同时不会产生额外的检索费用或运营开销。比如，如果客户将每年仅访问几次的数据从Amazon S3 Standard-IA迁移到Amazon S3 Glacier Instant Retrieval，就可节省高达近70%的存储成本。鉴于Amazon S3智能分层广受欢迎，如今亚马逊云科技还将它从Amazon S3扩展至云原生文件存储Amazon EFS。从该服务推出以来，已经为客户节省了超过2.5亿美元的存储成本。

除了Amazon S3智能分层服务外，亚马逊云科技还提供多种技术手段来监控并确保实际成本在预算之内。比如，可通过亚马逊云科技Budgets设定预算，在花费超过预算或者预测会超过预算时预警；可通过Amazon CloudWatch监控每日的存储用量和每分钟的数据访问请求，或者根据数据访问请求设定预警值。正是得益于这些创新，17年来亚马逊云科技将存储成本平均降低了70%，为全球客户累计节约了超过10亿美金的支出。

多层保护，确保数据安全与合规

亚马逊云科技一方面帮助客户把数据方便、高效地存储到云上，另一方面也在致力于为上云数据提供最大程度的安全保证，帮助客户确保合规。为此，亚马逊云科技还首创了安全责任共担模型，即亚马逊云科技负责云基础设施和服务的安全, 而客户负责云基础设施之上的操作系统、应用和数据安全。

通过多年持续不断的努力，如今亚马逊云科技打造出了多种安全服务，包括Amazon IAM、Amazon CloudTrail、Amazon Config、Amazon VPC Flow Logs等，可以实现多重认证和加密、持续监控，结合各种存储服务本身的功能，用户可以建立其一个多层次的数据安全防护体系。

以Amazon S3为例，在数据访问控制上，Amazon S3提供基于Attribute-based access control（ABAC）的控制策略，结合亚马逊云科技IAM服务、Amazon S3 Bucket Policy和Amazon S3 Object Tags等可以实现对S3的访问控制。ABAC相比传统的Role-Based Access Control（RBAC）拥有更多优势，包括可以随着资源的增加而扩展需求，可以节省Policy的数量，可以更粒度的进行控制，以及更快速地对团队进行修改等。

在数据保护上Amazon S3也提供了多种手段。比如，可以通过版本管理和多因子认证来减少数据错误删除，还支持存储加密和传输加密。而在监控方面，Amazon S3支持通过亚马逊云科技IAM Access Analyzer持续分析是否有资源被公开或者跨账号访问，以及验证各种策略是否正确书写等；还可以启用Amazon Macie服务，它使用人工智能算法对Amazon S3存储桶中的数据进行分析，以发现潜在的安全风险，保护敏感数据。

同样，亚马逊云科技的文件存储服务Amazon EFS也为客户提供了极强的控制力，比如可以通过POSIX权限严密控制对文件系统的访问；使用Amazon Virtual Private Cloud (Amazon VPC) 管理网络访问；使用亚马逊云科技Identity and Access Management (IAM) 控制对Amazon EFS API的访问；对静态和动态数据进行加密以保护存储的数据和传输中的数据等。

另外，亚马逊云科技还致力于简化安全策略的设置和管理。比如，通过创建访问点（Access Point），用户和应用程序可以使用它来访问Amazon EFS文件系统和Amazon S3，并根据IAM中定义的访问控制和基于策略的权限强制实现更细粒度的访问控制，以简化对对象和文件的共享访问。相比传统方式（如POSIX ACL）访问点在设置、管理和维护上都更为简单，提高了效率同时降低了潜在风险。

而在合规方面，亚马逊云科技的各项云服务符合PCI DSS、HIPAA、SOC 1/2/3等国际安全标准和条款，可以保障用户数据的合法性和安全性，帮助客户实现合规。

一站式数据备份与恢复，守住最后的防线

近年来，勒索软件事件一直处于高发态势，给企业数据安全带来了严重威胁。为了应对勒索软件的威胁、减少人为误操作带来的损失以及合规的需求，企业对数据备份和灾备的需求不断增加。然而，一直以来，云上备份就面临管理复杂、安全合规、高昂成本等挑战，这是企业面临的难题，也是亚马逊云科技要解决的问题。

亚马逊云科技的解决之道就是云上的一站式备份服务Amazon Backup——一种完全托管的、基于策略的备份服务，可以轻松地集中管理和自动化跨Amazon云服务的数据备份。

Amazon Backup支持亚马逊云科技的全部存储服务（块、文件、对象），以及各类数据库、计算和存储网关，可以一站式保护其中的数据。Amazon Backup通过图形界面来简化操作以帮助用户降低整个运维的成本，用户还可以通过预设的策略进行自动化的备份，降低手动备份带来的问题。

而安全合规方面，Amazon Backup深度集成了亚马逊云科技自带的KMS数据加密服务，整个备份操作权限数据访问权限都可以用IAM进行细颗粒度监控，满足个人信息安全规范等安全合规的要求。

对于很多企业，特别是传统企业，有不少数据保留在传统数据中心。对此亚马逊云科技提供了亚马逊云科技Storage Gateway服务，它部署在客户数据中心，可以与Amazon的数据中心连通，并通过Amazon Backup实现云下、云上数据的统一存储和备份。在此过程中，亚马逊云科技还与合作伙伴（如NetApp、IBM、Veritas等）开展合作，实现对来自第三方软件的数据进行存储和备份。利用Amazon Backup的图形化管理控制台，客户只需要点击鼠标，就能够实现跨应用，跨数据源的集中备份操作。用户可以针对不同的数据类型设置备份策略和备份数据保留周期，实现自动备份。Amazon Backup所有的备份数据都支持KMS加密，备份恢复操作权限和数据访问权限都可以通过IAM细颗粒度授权，同时支持备份库锁定和备份审计功能，满足企业法规遵从需求。勒索病毒攻击事件时有发生，国内也有很多企业都遭受到了巨大损失，利用Amazon backup的集中数据备份，以及备份库锁定功能，可以有效的防止勒索病毒的攻击，生产数据备份到备份库，设置备份库锁定功能，病毒或者恶意操作都无法改变或者删除备份库里的数据。这样能确保客户在遇到生产数据损坏或者遇到恶意攻击时，能够有效恢复数据，

最后，值得一提的是，亚马逊云科技云服务在种类丰富的各种云服务外，还提供了各种安全最佳实践。作为用户，利用好这些服务，并遵守亚马逊云科技的安全最佳实践，就可以为自己的数据提供最大程度的安全保障。

结束语

在一个全面数字化和云化的时代，数据已经成为关键生产要素，数字化和云化能够帮助企业优化业务流程，提高效率和灵活性，企业可以实现更快、更准确和更简单的业务操作，同时也能够快速地适应市场变化和业务需求的变化。作为云时代的技术引领者，亚马逊云科技在存储领域的探索，帮助正在数字化转型中的各行各业从数据中收获价值打下了很好的基础。同时，其产品和技术创新的思路给业界提供了很好的参考。

点击“阅读原文”，了解Amazon Backup更多信息！

Istio在Rainbond Service Mesh体系下的落地实践

两年前Service Mesh（服务网格）一出来就受到追捧，很多人认为它是微服务架构的最终形态，因为它可以让业务代码和微服务架构解耦，也就是说业务代码不需要修改就能实现微服务架构，但解耦还不够彻底，使用还是不方便，虽然架构解耦了，但部署还没有解耦。

• 无法根据不同环境或客户需要选择合适的Service Mesh框架。
• 无法做到在开发环境不用学习和使用Service Mesh，生产环境按需开启。

插件式 Service Mesh架构实现思路

目前成熟的ServiceMesh框架也有许多，但是对于用户而言。并不存在万能的ServiceMesh框架，可以解决各种场景的问题。因此我们希望对于用户而言，他只需要关心自己的业务代码。而应用的治理能力，则可以通过不同的ServiceMesh框架进行拓展。用户的业务代码与ServiceMesh框架完全解耦。如下图所示。用户可以随时替换某个应用所使用的ServiceMesh架构。选择与业务最匹配的解决方案。

基于以上思路，我们可以将istio、linkerd、dapr等微服务架构做成插件，开发过程中完全不需要知道Service Mesh框架的存在，只需要处理好业务的依赖关系，当交付到生产环境或客户环境，有些需要性能高、有些需要功能全、有些客户已经指定等各种差异化需求，根据环境和客户需要按需开启不同类型的插件即可，当Service Mesh框架有问题，随时切换。这样Service Mesh框架就变成赋能的工具，老的业务系统重新部署马上就能开启服务治理能力。

Rainbond就是基于上述思路实现的，当前版本已经实现了三个服务治理插件。

• kubernetes 原生Service 模式
• 基于envoy的Service Mesh模式
• Istio服务治理模式

后面我们详细讲解Istio服务治理模式的使用过程。

使用Istio治理模式的实践

有了以上概念，我们可以来看看Rainbond如何与Istio结合。在Rainbond中，用户可以对不同的应用设置不同的治理模式，即用户可以通过切换应用的治理模式，来按需治理应用。这样带来的好处便是用户可以不被某一个ServiceMesh框架所绑定，且可以快速试错，能快速找到最适合当前业务的ServiceMesh框架。

安装Istio 控制面（control plane）

首先在切换到Istio治理模式时，如果未安装Istio的控制面，则会提示需要安装对应的控制面。因此我们需要安装Istio的控制面，控制面在一个集群中只需安装一次，它提供了统一的管理入口，用来管理工作在Istio治理模式下的服务。完成配置下发等功能。结合Rainbond现有的helm安装方式，我们可以便捷的安装好对应的组件。

1. 创建团队

在5.5.0版本中，我们支持了用户在创建团队时指定命名空间。由于默认helm安装的命名空间为 istio-system ，所以为了减少用户配置。我们首先需要创建出对应的团队。如下图所示。团队英文名对应的则是该团队在集群中的命名空间。此处填写 istio-system 。

2. 对接商店

Rainbond支持基于helm直接部署应用，所以接下来对接Rainbond官方helm仓库，后续基于Helm商店部署Istio即可， 在应用市场页面，点击添加商店，选择helm商店，输入相关信息即可完成对接。

商店地址：https://openchart.goodrain.com/goodrain/rainbond

3. 安装 Istio 控制面

商店创建完成后，即可看到对应的 helm 应用，目前Rainbond提供了 istio 1.11.4 版本的helm包，根据 Istio官方文档，该版本对Kubernetes集群的版本支持为 1.19, 1.20, 1.21, 1.22。

• 安装 base 应用

  选择helm商店中的base应用进行部署，团队选择之前创建的命名空间为 istio-system 的团队。该应用包主要部署了Istio相关的集群资源和 CRD 资源。

  

• 安装 istio-discovery 应用**

  同上述base应用一样，选择正确的团队。安装 istio-discovery 应用。有了这两个应用，就可以拥有 Istio 基础的治理能力了。

示例应用开启Istio治理模式

1. 切换治理模式

我们以SpringBoot后台管理系统 若依 为例，如下图所示，用户可以先从开源应用商店安装一个若依SpringBoot 应用，版本选择3.6.0，点击治理模式切换，选择Istio治理模式。

在点击切换为Istio治理模式后，会需要用户手动设置内部域名，此处的内部域名将会是该组件在Kubernetes集群中的service名称，在同一个团队下唯一。这里我们修改为可读性较高的内部域名。

2. 修改配置文件

在这一步完成后，我们还需要进入ruoyi-ui 挂载一个新的配置文件。这主要是因为默认情况下，ruoyi-ui 的配置文件web.conf 中后端服务地址为 127.0.0.1，在之前使用 Rainbond 内置 ServiceMesh 模式时，由于 Rainbond 会获取到后端服务的地址，注入到ruoyi-ui 内部, 赋予ruoyi-ui 一个本地访问地址（127.0.0.1）访问后端服务。所以无需修改就能使用。

但使用 Istio 治理模式时，组件间通过内部域名进行通信，因此需要通过挂载配置文件的方式修改对应的代理地址，ruoyi-ui 的配置文件可以通过右上方的Web终端 访问到容器中，复制/app/nginx/conf.d/web.conf 这个文件的内容。修改代理地址后保存，如下图所示。之前我们设置了控制台的内部域名为ruoyi-admin，所以这里替换为ruoyi-admin。

3. 重启应用

在完成以上两步后，我们需要重启整个应用。在启动应用后，进入组件页面查看，应该可以看到每个组件都有一个类似的 Sidecar 容器，这就是Istio的数据面 (data plane)，在应用切换为Istio治理模式以后，该应用下的所有组件都会自动注入对应的 Sidecar 容器，不需要用户额外设置。

至此，该应用已纳入Istio治理范围。用户如果需要对该应用有更多的配置，则可以参考 Istio官方文档 进行扩展。

通过Kiali监控和管理Istio

在之前的步骤中，我们使用 Istio 治理模式纳管了 若依 。接下来则带大家一起看看如何使用 Kiali 观测应用间的通信链路。在这一步中，用户需要有 kubectl 命令。

1. 安装 prometheus

在Istio中，各个组件通过暴露HTTP接口的方式让Prometheus定时抓取数据（采用了Exporters的方式）。所以Istio控制平面安装完成后，需要在istio-system的命名空间中部署Prometheus，将Istio组件的各相关指标的数据源默认配置在Prometheus中。

同上述base应用一样，选择正确的团队，安装Prometheus应用。

2. 安装kiali

kiali提供可视化界面监控和管理Istio，能够展示服务拓扑关系，进行服务配置。

安装 kiali-operator 应用，同上述base应用一样，选择正确的团队。

安装过程将自动创建Service，通过Rainbond平台第三方组件的形式可将 kiali 的访问端口暴露出来。如下图所示：

在端口界面添加访问端口，添加以后打开对外服务使用生成的网关策略即可进行访问。

kiali登录时需要身份认证token，使用以下命令获取token：

kubectl describe secret $(kubectl get secret -n istio-system | grep istiod-token |awk '{print $1}') -n istio-system

访问到kiali以后，在Applications一栏，选中应用所在的命名空间，就可以看到我们刚刚创建的应用。点击进入，可以看到如下的流量路线。

在 Graph 一栏，也可以看到对应的应用内的流量请求。更多的配置及相关功能参考 Kiali官方文档

总结

本文简单介绍了在Rainbond中使用Istio治理模式的操作。以及Rainbond与Istio治理模式的结合。Rainbond为用户提供了一个可选的插件体系，使用户可以根据自己的需求选择不同的Service Mesh框架。在与Istio的结合上，我们主要为用户完成了指定应用数据平面的注入。用户也可以通过该机制扩展自己所需的ServiceMesh框架。后续文章我们将详细讲解如何制作插件，尽请关注。

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Github：https://github.com/goodrain/rainbond

官网：https://www.rainbond.com?channel=k8s

微信群：请搜索添加群助手微信号 wylhzmyj

钉钉群：请搜索群号 31096419

 

Rainbond 5.5 版本主要优化扩展性。服务治理模式可以扩展第三方 ServiceMesh 架构，兼容kubernetes 管理命令和第三方管理平台。

主要功能点解读：

1. 支持 Istio，并支持扩展第三方 ServiceMesh 框架

Rainbond 专注于无侵入，松耦合的设计理念。在当前版本中，Rainbond 引入了应用级治理模式的切换功能，实现了服务治理能力的动态切换，无需业务逻辑变更，为业务提供了不同的治理能力。可以通过应用级插件的形式扩展第三方 ServcieMesh 框架，比如 Istio、Linkerd、Dapr 等，本次我们优先支持了Istio，用户可以通过 helm 安装 Istio 相关组件，实现应用治理模式的切换。从而享受到Istio相关的治理能力。如下图所示：

我们希望用户最终使用时，服务治理能力与业务逻辑是完全解耦的，用户可以根据不同的业务使用不同的治理能力。可以根据自己的需要扩展不同的治理模式，后续我们会有专门的文章来详细介绍如何扩展第三方 ServiceMesh 框架。

2. 兼容 kubernetes 管理命令和第三方管理平台

在之前的版本中，我们以应用为中心，使用户可以便捷的管理自己的业务。但通过Rainbond生成的名字空间、应用名和服务名使用 UUID，对熟悉 Kubernetes 的人非常不友好，在 Kubernetes 展示的 ID 无法跟业务关联，就无法使用 Kubernetes 命令或 Kubernetes 的第三方工具管理。因此我们现在支持了集群内各类资源的重命名。用户可以自定义团队、应用、服务、组件、镜像的英文名，在Kubernetes 中会以英文名展示。

用户设置了应用的英文名为 rbd，分别设置了组件的英文名后，在集群生成的资源如下图所示。

详细变更点：

新增功能

• 【应用管理】支持Istio治理模式的切换；
• 【应用管理】支持修改应用和组件的集群资源名；

优化功能

• 【组件管理】优化组件构建的镜像名称；
• 【数据库】新版本集群数据库使用utf8mb4编码；
• 【升级】优化应用升级时无变更组件不进行更新操作；
• 【组件管理】优化组件首次设置健康检测的提示；

BUG 修复

• 【组件管理】修复实例运行内存为0的问题；
• 【网关】修复网关策略跳转页面错误的问题；
• 【应用管理】修复应用运行组件数展示错误的问题；
• 【应用管理】修复应用无法正常回滚的问题；
• 【插件管理】修复默认插件构建失败的问题；
• 【应用管理】修复发布应用时，插件分享事件同步发生错误的问题；
• 【插件管理】修复安装插件不生效的问题；
• 【组件管理】修复域名创建的第三方组件无法通过内部依赖访问的问题；
• 【应用管理】修复TCP策略网关端口可以随意设置的问题；
• 【升级】修复应用升级失败重试无响应的问题；
• 【应用管理】修复helm应用状态展示错误的问题；
• 【升级】修复回滚功能不可用的问题；
• 【组件管理】修复内部域名可以重复的问题；
• 【插件】修复插件内存不限制时报错的问题；
• 【升级】修复配置文件升级后无法修改的问题；
• 【组件管理】修复创建中组件无法继续部署的问题；

References Link

[1] Rainbond 5.5安装

[2] Rainbond 5.4升级到5.5

[3] Istio控制平面安装

---

Rainbond 是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Github：https://github.com/goodrain/rainbond

官网：https://www.rainbond.com?channel=k8s

微信群：请搜索添加群助手微信号 wylhzmyj

钉钉群：请搜索群号 31096419

CentOS如何改变云Linux领域？

Red Hat在2021年底将丢弃CentOS 8，用户们纷纷考虑面前的选择。
作者：Matt Asay  编译：沈建苗

在前不久的AWS re:Invent大会上，大型机现代化、数据库更新版和基于ARM的 Graviton3等新品赚足了眼球，诸位看官可能因此疏忽了一点：Amazon Linux 2022。AWS首席执行官Adam Selipsky在主题演讲中并没有提及它，但AWS计算服务副总裁Deepak Singh确实为此发了推文。但Amazon Linux 2022可能名至实归，因为它是那种了不起的产品，旨在提供稳定性、安全性和性能，又不显山露水。

这也是一个值得关注的版本。Amazon Linux 2022首次不基于Red Hat Enterprise Linux（RHEL）代码，而且从未基于CentOS。CentOS这个长期的RHEL克隆版在2020年底掀起了不小的动静，当时Red Hat宣布不使用定点（fixed-point）发布模式，改而使用“基于流”的滚动发布模式。相反，Amazon Linux 2022而是基于Fedora社区上游项目。

觉得这没什么大不了？那么你也许应该问问其他大型云提供商：鉴于Red Hat已宣布CentOS 8将于2021年底寿终正寝，它们打算怎么办。想销售美国政府基于CentOS的服务？CentOS不再符合FedRAMP。改用RHEL或另一款受支持的操作系统，不然休想与联邦政府做生意。我去。

无论是AWS有先见之明还是纯属走运，AWS专注于Fedora很可能带来可观的回报。但是对于白蹭CentOS的日子即将到头、下一步不知道该如何是好的企业来说，也许有必要记住一点：“免费软件”常常不是免费的。

 

“IT史上被滥用最多的软件”

每家云供应商立足于CentOS有其道理。毕竟，每家都这么做，每家。不妨看看全球一些最大的软件即服务（SaaS）提供商的底层操作系统，你会发现CentOS的影子无处不在。深入了解IBM的咨询业务，会发现该公司多年来如何告诉其客户“就使用 CentOS”。永远不会允许别人出售超昂贵包包仿制品的欧洲时尚品牌运行CentOS。中国的整个电信基础设施都运行在CentOS上。（是的，千真万确。）Facebook也基于CentOS。

CentOS的这种广泛使用也并不仅限于测试和开发实例。有一家大型云提供商的许多大客户在运行CentOS，CentOS的知情人士提到了这家云提供商的高管所说的这番话：“CentOS是IT史上被滥用最多的软件。CentOS前十大用户拥有超过50000个实例，它们是《财富》100强中的知名公司。它们知道自己在做什么。并不是开发人员运行开发/测试实例。它们不是小公司。”

原因何在？因为CentOS一直被认为很安全。当然，Red Hat试图告诉客户，在生产环境中跑CentOS相当于手持剪刀在跑步（“尽管去跑吧，但你一定会受伤！”），但事实上它非常接近RHEL，而Red Hat花数年时间培育市场、传达“RHEL即安全”的讯息。

CentOS Stream在Red Hat收购CentOS几年后宣布发布，Red Hat反而使CentOS不太安全。突然间，CentOS 从“可信赖的RHEL克隆版”变成了“有点拉垮的RHEL测试版代码”。如前所述，许多人纷纷抱怨，但不清楚他们是否会极喜欢这个替代版。多年来，CentOS社区一直努力跟上人气。人气旺是好事，但当 (a) 你没有因这种人气而获得报酬，以及 (b) 全球一些最大的公司（银行和电信公司等）在CentOS上运营其大量的业务，因此要求对代码进行各种更改时，情况就不那么好了。这是导致维护人员倦怠的主因，也是企业在跑时被所持的剪刀所伤的主因。

必须有所给予。

Red Hat出面稳定CentOS社区的办法是雇用主要的贡献者。就Red Hat而言，它希望为OpenStack和OpenShift等更高级的社区项目提供稳定的代码基础。Fedora无法提供这个基础，因为它的迭代步伐太快了。当然，Red Hat也想让吃白食的企业明白，不存在真正意义上的“免费软件”。为了避免被开发人员和小公司讨厌，Red Hat对RHEL开发者版本进行了重大更改，使其极易访问或使用（即免费！），同时让RHEL可供最多16台服务器免费使用，从而为学校及其他小组织提供了一种经济高效的方法，以运行经过测试、认证和支持的Linux。

云端的高光时刻

这一切无法帮助不得不应对CentOS变化的托管服务提供商。正如我所认为，这些公司不需要Red Hat来支持，它们多年来一直在不受支持的情况下运行CentOS。但是它们依赖的Linux的本质发生了变化，而且是重大变化。运行经过良好测试的企业级Linux的克隆版是一回事，在没有任何安全或性能保障的测试版软件上运行完全是另一回事。

这开始看起来酷似“手持剪刀在跑”的场景，Red Hat在CentOS Stream之前试图用这种场景来抹黑CentOS，但未能如愿。鉴于操作系统（一家公司的应用程序、数据库等依赖的基础）相比企业在上层软件方面的高昂支出较为便宜，“捡了芝麻丢了西瓜”的做法突然显得很可笑。

该怎么办？一个显而易见的答案是向Red Hat支付RHEL费用。针对不愿意这么做的用户，谷歌建议使用CentOS的替代版，并与Red Hat合作，帮助客户迁移到受支持的操作系统。微软对Azure客户给出什么样的建议则不太清楚。AWS已经改用Fedora，并提供支持。是的，这底层代码也许用alpha代码来加以描述最为恰当，但AWS工程师会积极为上游做出贡献以改进它，AWS全力支持它。

AWS的竞争对手在这方面要棘手一点。没有人真的想支持另一个Linux发行版。这就是我们选用RHEL、SUSE和Ubuntu的原因。AWS第一个向市场推出了其Linux。鉴于其市场份额，AWS可能是唯一一家实力大得足以说服独立软件开发商（ISV）及其他厂商支持与RHEL不兼容的Linux的供应商。现在，谷歌和微软要弄清楚如何在后CentOS时代存活，它们可没有足够大的市场份额来说服ISV及其他厂商支持其操作系统。记住，Red Hat赢得Linux市场的手段是围绕其经过认证的操作系统创建一个生态系统。坊间有传闻称，谷歌和微软可能联合支持一款与SUSE兼容的产品，但现在下结论为时过早。

唯一可以肯定的是，Linux再次备受关注。这可能不是一件好事，因为它理应是不会引起任何人注意的幕后基石。

文章来源：
https://www.infoworld.com/article/3643708/how-centos-changes-the-cloud-linux-game.html

我们在使用智能手机的时候，手机APP从应用市场一键安装，安装好即点即用，当有新版本一键升级，如果不想用了长按图标删除，整个过程非常简单，小朋友都能熟练掌握。而对于企业应用，由于结构复杂、可用性要求高、配置多等特点，导致企业应用的管理工作异常复杂。企业内部一般都会有专门的运维工程师来负责保障企业应用的正常运行。

Rainbond 是一款云原生企业应用管理平台，本文将以它为例讲解，如何像管理手机 APP 一样简化管理企业应用。

建立企业应用商店，从应用商店一键安装企业应用

手机 APP 的安装已经做到了极致的简单，在预装好的 AppStore 中一键安装想要的APP即可。这种一键安装的体验流程，哪怕一个小朋友都可以很好的掌握。企业应用部署难度大，组件数量多，其安装的复杂程度远高于手机 APP 。那么在企业应用的安装领域，能否做到安装手机APP一样的一键式体验呢？

类比手机 APP 的安装过程，应用商店这个集合了大批 APP 的平台是必不可少的一环，正是有苹果 AppStore、Google Play 这样生态繁盛的应用商店，才让手机消费者随心所欲的安装手机 APP。Rainbond应用商店是企业级的AppStore。每个用户都可以将自己部署在 Rainbond 上的企业应用发布到应用商店中去，供其他用户使用，其他用户只要从应用商店一键安装和升级，使用体验和手机AppStore的体验类似。

为了最终用户的使用体验，开发手机APP的企业需要按应用商店的标准开发和上架，企业应用商店的实现也是类似的思路，企业应用的供应商需要按企业应用商店的标准打包和上架，Rainbond内置的应用商店有一整套的应用打包、测试和上架过程，比如从源码打包、二进制文件打包、容器打包等，这些打包过程都不需要改动原有代码。按应用商店的规范打包和上架，不仅简化了应用的安装和升级过程，同时也建立了企业应用的验收标准。

企业应用管理复杂，该如何简化管理？

对于一个手机 APP 而言，实际上我们可以做的管理操作很少，仅仅涉及到安装、升级、删除。而一个企业应用则要复杂得多，一个企业应用所需要的管理操作，至少包含了以下这些点：

• 生命周期管理：就像手机用户需要安装、使用、升级、删除 APP一样，安装、升级、启动、关闭、删除等生命周期管理相关的操作，是企业应用所需要的最基础的管理操作。
• 批量管理：手机 APP 只有一个组件需要管理，而企业应用往往是多个服务组件相互依赖组合形成的。所以会需要有批量操作的需求。
• 资源分配：手机用户从来不用关心需要为一个 APP 分配多少资源，而企业应用的管理者必须关心为每个组件分配合理的计算资源。计算资源分配不足会让企业应用运行不畅甚至无法运行，过多的分配计算资源会导致资源浪费。
• 伸缩特性：手机 APP 并没有运行多份的需求，它只需要保证在手机中正常运行， 满足主人的个人使用压力即可。企业应用无论是在高可用方面还是在抗并发方面，都会对横向伸缩能力提出要求。
• 可观测性：手机用户从来不关心是否能够看到手机 APP 的运行状态，只关心它们的功能。但是企业应用管理者会对企业应用提出很高的可观测性要求，包括运行状态、资源占用、性能表现、运行稳定性等。
• 故障恢复：手机用户允许 APP 偶尔出现闪退，无非是重新打开一次罢了。而企业应用管理者对企业应用的期待是，即使企业应用出现了问题，也可以快速从故障状态中恢复过来。
• 迁移/备份：手机 APP 的用户数据都保存在云端，数据的迁移、备份操作简单。企业应用重视数据，对迁移备份等操作要求很高，有的场景甚至要求跨集群迁移备份。

经过对比，可以发现企业应用在管理方面需要注重的点，比手机APP复杂得多。但这不意味着企业应用管理人员一定要付出更多的努力来管理企业应用。选择正确的企业应用管理工具，会使得企业应用管理工作事半功倍。

Rainbond从三个方面简化企业应用的管理：

1. 让常规的管理简单容易上手，比如：安装、升级、启动、关闭、删除、伸缩、配置域名等管理操作都可以一步完成。
2. 复杂的运维过程实现自动化，比如：安装/升级/启动的操作过程、健康检测、服务高可用、自动伸缩等。
3. 过程实时监控和可视化，由于管理过程实现了简单操作和自动化，就需要加强监控和可视化了解应用运行情况，做到过程可控可管。

让企业应用常规管理简单容易上手

前文已经分析过，手机用户对 APP 的管理操作是仅限于开启、关闭等简单的操作。对于企业应用而言，我们希望企业应用管理者主动发起的管理操作，也是足够简单的操作。企业应用管理人员完全通过图形化界面，来完成对企业应用的生命周期管理操作。

对于企业应用整体而言，可以执行批量的管理操作：

涉及到生命周期管理的操作包括但不限于：

• 企业应用整体的启动、停用、更新、构建、升级
• 面向企业应用内部所有组件的批量启动、关闭、更新、构建、重启、删除

对于希望将企业应用完整的迁移到其他集群，或者做一份备份的场景而言，图形化操作的迁移/备份功能可以解决问题：

对于指定的服务组件而言，可以进行的主动管理操作会更多：

除了较为常见的生命周期管理之外，企业应用的管理者还可以有更多的主动操作：

• 版本管理，在多个构建版本之间一键升级或回滚

• 伸缩管理，主动的为服务组件设置计算资源、实例数量

• 环境配置，主动为服务组件设置环境变量，挂载配置文件

• 存储管理，主动为服务组件添加持久化设置，使数据持久化的保存

• 端口管理，主动为服务组件添加端口访问策略

• 插件管理，主动为服务组件安装可以扩展运维能力的插件

• 进入 Web终端，直接操作当前服务组件的容器shell环境

常规企业应用管理操作基本都是UI界面，过程也不需要学习底层技术，通过界面摸索就可以上手。

复杂的运维过程实现自动化

企业应用确实比手机 APP 复杂太多，但是我们又希望企业应用的管理者尽量少操管理的心，那么提供自动化的运维能力就十分有必要。

Rainbond 被设计成一款具备强大自动化运维能力的平台。这些自动化运维能力，可以最大限度的解放企业应用管理人员的双手，切实提升生产力。这些自动化运维能力提炼自许多工程师长久以来的运维工作经验，这些能力往往表现在企业 IT 系统的底层，平日里不显山露水，但是却关乎企业应用运行的好坏。

1. 常规管理的过程实现自动化企业应用的常规管理本身是挺复杂的，为了前端的操作简单，后端的实现过程就必须自动化。 比如：
   • 安装过程自动化，安装过程需要为每一个服务自动化完成软件包安装、服务配置、端口管理、服务启动等步骤。
   • 升级过程自动化，升级过程需要自动化完成对比版本差异、差异安装、滚动升级等步骤。
   • 启动过程自动化，当一个企业应用有多个子服务时，还需要自动处理它的服务启动顺序。
2. 健康检测与故障恢复企业应用管理人员不希望为了应对不知何时会发生的企业应用故障而每时每刻值守在机房。因此 Rainbond 提供健康检测能力，来替代企业应用管理人员，时刻关注着企业应用的健康状况。并且提供可选的异常处理手段，在异常发生时自动处理。

   Rainbond 平台支持两种模式的探针来自动检测服务组件中所有实例的健康状况。TCP模式的探针，会每隔一段时间侦测服务组件的指定端口是否可以联通，这种检测是基于网络和端口的联通性来实现的。而HTTP模式的探针，会每隔一段时间，请求指定的URL，并根据HTTP返回码来判断实例的健康状况。相对而言，TCP探针应用的范围更广泛，而 HTTP 探针会更加精确。因为可能存在这样一种软件设计缺陷，WEB SERVER 处于正常工作状态，端口可以正常监听，但是业务接口已经无法提供正确的返回，这对于最终用户而言，也是一种应该被检测到的错误。

   对于检测失败之后的处理，平台提供两种策略，下线与重启。

   将问题实例从负载均衡中下线，这是一种降级行为。触发下线后，不会再有新的请求到达问题实例，问题实例从巨大的访问压力中得以缓解。接下来，如果服务组件足够健壮，它会在处理完大量的积压请求后恢复，重新通过健康检测后上线。这里包含一个隐藏的假设，要求服务组件具备多实例特征，否则问题实例的下线会导致服务组件整体无法提供服务。

   重启则是一种相对武断的处理方式。但不可否认的是，在服务组件不那么健壮的情况下，重启实例是最简单有效的恢复手段。

   

3. 高可用能力Rainbond 为企业应用提供了高可用能力的支持。在一个 Rainbond 集群中，往往存在多种不同身份的服务器节点，而每种不同身份的服务器节点也不止一台。这意味着 Rainbond 本身就是高可用的，运行在其上的企业应用，也可以自由的在不同的宿主机节点之间漂移。

   在 Rainbond 集群中的某台服务器出现故障时，Rainbond 集群并不会受其影响，也会将受到服务器故障影响的企业应用重新调度到其他正常的服务器中去。企业应用管理人员只需要在事后修复故障的服务器，整个 Rainbond 集群又会完成自愈，而企业应用在这个过程中受到的影响是可以忽略不计，尤其是当企业应用本身伸缩了多个实例的状态下，可以做到最终用户无感的处理体验。

4. 自动伸缩能力如果企业应用的最终用户是人，那么它的访问压力情况，都会有潮汐特征。好比一款供企业内部人员使用的OA系统，工作日的流量远比休息日高，工作时间的流量远比下班时间高。那么可否让这款 OA 系统根据流量的大小，自动调整实例的数量。令其忙时启动足够数量的实例抵御访问压力，闲时自动降低实例数量，将资源留给其他企业应用。Rainbond 平台可以赋予企业应用自动伸缩的能力。

   Rainbond 平台对于其托管的每个企业应用的当前状态了如指掌。当然也了解当前企业应用的资源使用数量是否已经接近分配的上限。通过自动伸缩的设置，可以为企业应用设置一个上限，当 Rainbond 发现企业应用使用的资源已经超过这个设定值时，自动的扩展实例的数量。这个设定值，可以是内存使用量/率或CPU使用量/率，亦或是两种资源的综合设定值。

   

管理过程可观测和可视化，做到可控可管

手机用户不会想着观察 APP 内部的运行状态，但是企业应用管理人员不这么想。可观测性是一切管理工作的前提，只有看得见，才能摸得着。

Rainbond 提供的可观测性无处不在，从集群维度开始，到应用级别，最终到每一个服务组件级别，都体现着丰富的可观测性。

对于一个企业应用而言，看到它内部的拓扑结构，和所有组件的运行状态是最基本的可观测性要求。Rainbond 提供了应用拓扑图界面，并根据不同的颜色来体现每一个服务组件的运行状态。绿色代表运行中，黑色代表已停止，而红色代表服务组件处于异常状态。

对于单个服务组件而言，其可观测性的粒度要更细致。服务组件的总览页面中，描述了当前服务组件的详细信息，服务组件的每个实例，也都体现自己的运行状态。

下方的操作记录，更是详细描述了服务组件发生过的每一件事。

服务组件的监控页面，集中的体现了有关其运行状态的各种可视化图表。

• 体现业务性能情况的实时分析曲线

• 有助于优化程序的5分钟请求排行

• 各个实例的资源用量曲线

• 支持基于 Prometheus 体系的 Exporter 指标自行绘图

Rainbond 的监控大屏系统，提供全局可观测性的中心。

写在最后

Rainbond 提供一个解决企业应用的管理问题的全新思路，它不仅优化了管理和使用体验，还能高效管理应用供应商，应用商店也让管理人员对应用自主可控，减少对供应商的依赖。

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Kubernetes 1.23发布：双栈IPv4/IPv6、CronJobs和临时卷

作者：Jack Wallen  编译：沈建苗

在云原生开发界，一眨眼工夫，你就会错过某些东西。发展速度就是这么快，快到仿佛昨天（实际上是8月22日）刚发布了Kubernetes 1.22，今天就迎来了Kubernetes 1.23 GA（正式版）。这个新版本功能丰富，增强之处超过45项（其中11项已升级到稳定版，15项已改进，19项是全新的）。虽然这些新功能可能不会全部跻身Top 10，但一些功能对使用Kubernetes的人而言可能大有帮助。然而，真正的焦点在于1.23中已升级到正式版（即稳定版）的功能，因此它们已准备好用于生产环境。

不妨先看看已升级到稳定版的功能（因为这些是你想立马开始使用的功能），然后介绍所有其他较为隐秘的改进。

升级到稳定版

首先你会发现四项非常令人兴奋的功能：IPv4/IPv6双栈支持、CronJobs（计划任务）、临时卷和HPA API。不妨逐一介绍。

 

IPv4/IPv6双栈支持

有了IPv6/IPv6双栈支持，Kubernetes现在可以在集群中直接支持双栈模式。这意味着你可以将IPv4地址和IPv6地址分配给任何特定的pod或服务。这是使用.spec.ipFamilyPolicy字段来配置的，该字段可设置为以下值之一：

•SingleStack

•PreferDualStack

•RequireDualStack

要使用双栈支持，你需要将.spec.ipFamilyPolicy设置为PreferDualStack或RequireDualStack。该功能在Kubernetes中默认启用，还包括通过IPv4和IPv6地址进行的pod集群外出站路由。

CronJobs
有了CronJobs功能，就可以在Kubernetes集群中运行周期性任务。Kubernetes CronJobs与Linux cron系统非常相似。CronJobs在Kubernetes 1.4问世后就已存在了，自从它在版本1.5中获得CRI支持以来就在生产环境被广泛接受。

CronJob在YAML文件中定义如下：
kind: CronJob

每10分钟输出一次“Hello Newstack”的示例CronJob清单文件可能如下所示：

对于那些不知道cron语法的人来说，它就像这样：

MINUTE（分钟） HOUR（小时） DAY OF MONTH（月日） MONTH（月） DAY OF WEEK（星期几）

如果你不确定如何创建cronjob，强烈建议从Crontab Guru（https://crontab.guru/）开始入手，该编辑器让你可以将值插入到cronjob
，看看它们到底生成了什么。

临时卷

自Kubernetes 1.19以来，临时卷就已存在，让你可以为特定的pod创建卷，pod终止后删除临时卷。换句话说，这些是临时卷。

Kubernetes支持四种类型的临时卷，它们是：

•emptyDir—Pod启动时可用的空卷，使用来自kubelet基本目录或内存中的存储空间。
•configMap、downdownAPI、secret—将不同类别的Kubernetes数据注入到指定的Pod中。

•CSI临时卷—类似其他类型的卷，但由特殊的CSI驱动程序提供。

•通用临时卷—由所有存储驱动程序提供（支持持久存储）

使用临时存储的示例清单文件可能如下所示：

HPA API v2

Horizo​​ntal Pod Autoscaleer API对Kubernetes来说并不陌生。实际上，它在2016年就首次引入了。该功能负责自动扩展复制控制器、部署、副本集或状态集中的Pod数量。基于以下类型的指标来加以扩展：

•资源使用情况—当Pod超过内存或CPU使用情况的阈值时。这可以表示为原始值或百分比。

•自定义指标—这基于Kubernetes报告的指标（即每秒客户端请求率）。

•外部指标—这基于外部应用程序或服务提供的指标。

Autosaclers使用控制循环来运行，周期则由–horizo​​ntal-pod-autoscaler-sync-period标志来控制。默认值是15秒。在控制循环期间，控制器根据Horizo​​ntalPodAutoscaler定义中配置的指标来查询Pod的资源使用情况。

弃用的功能和升级为Beta版的功能

Kubernetes 1.23也有三项值得注意的弃用功能。这包括：

•HPA v2beta2 API

•FlexVolume

•针对klog的标志

两项功能也升级为Beta版，包括：

•PodSecurity—取代了PodSecurityPolicy准入控制器。
•结构化日志—来自kubelet和kube-scheduler的大多数日志消息已经过转换，建议用户尝试JSON输出。

处于Alpha版的新功能

Kubernetes 1.23还包括几项现处于alpha版的新功能。这包括：

•CRD的表达式语言验证—如果启用CustomResourceValidationExpressions，自定义资源将由使用通用表达式语言（CEL）的规则进行验证。

•服务器端字段验证—如果启用ServerSideFieldValidation，检测到请求中未知或重复的字段时，用户将收到来自服务器的警告。

•OpenAPI v3—如果启用OpenAPIV，用户将能够为所有Kubernetes类型请求OpenAPI v3规范。

想了解新版本的更多信息，请查阅完整的发布说明：https://www.kubernetes.dev/resources/release/。

文章来源：https://thenewstack.io/kubernetes-1-23-dual-stack-ipv4-ipv6-cronjobs-ephemeral-volumes/

 

Rainbond是一体化的云原生应用管理平台，它提供“以应用为中心”的抽象，使用者不需要学习K8s和容器，平台将K8s和容器封装在内部，这种封装方式能极大提高使用的易用性和安装的便利性，但封装的内部组件如何替换是一个问题，本文将讲解如何使用Harbor替换掉Rainbond原有的默认镜像仓库。

Harbor简介

Harbor 是一个用于存储和分发Docker镜像的企业级Registry服务器，也是首个中国原创的云原生基金会（CNCF）的开源企业级DockerRegistry项目，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。

通Harbor解决Rainbond镜像管理问题

​ Rainbond之前默认使用的是Docker 提供的基础Registry，使用的过程中有很多问题，例如镜像安全性，镜像清理复杂麻烦等等问题，经过不断的调研，而Harbor不仅能解决这些问题，还能扩充很多镜像管理能力，Harbor 的功能主要包括四大类：多用户的管控（基于角色访问控制和项目隔离）、镜像管理策略（存储配额、制品保留、漏洞扫描、来源签名、不可变制品、垃圾回收等）、安全与合规（身份认证、扫描和CVE例外规则等）和互操作性（Webhook、内容远程复制、可插拔扫描器、REST API、机器人账号等）。

对接Harbor

​ 目前harbor支持两种形式对接Rainbond,一种是作为rainbond内部基础存储仓库，另外一种就是作为外部自定义镜像仓库。

• Harbor作为Rainbond内部基础存储仓库，进行对接非常简单，只需要在初始化平台集群的时候进行自定义即可。

​

​ Yaml文件的格式要求非常严格，避免大家在配置的时候出现问题，已把正确的yaml文件放在下面，复制就可以使用。

​ 注意：一定修改仓库的名字，仓库的项目名称, 用户名，以及密码，不然会出现镜像上传失败的问题。

1. 例：
2. apiVersion: rainbond.io/v1alpha1
3. kind: RainbondCluster
4. metadata:
5. name: rainbondcluster
6. namespace: rbd-system
7. spec:
8. imageHub:
9. domain: www.est.com/test
10. password: Harbor12345
11. username: admin

`

• Harbor作为rainbond的外部仓库进行提供服务，是基于harbor以及rainbond的webhook功能，配置如下。
• 保证组件已经开启了镜像仓库的webhook功能，且应用状态不是已关闭状态，并且需要将应用的 webhooks url 配置到目标镜像仓库的 webhooks 中

• 目标镜像仓库里面，新建一个webhook，然后在 Endpoint 地址填写应用的 webhooks url，配置符合需求的触发事件类型即可

• 通过Harbor实现镜像可视化存储管理，提高了工作的便利性。

• 基于Rainbond进行构建的时候实现漏洞自动扫描，提高了安全管理。

• 通过镜像自动清理的策略，合理利用存储，降低存储成本。
• 推荐使用策略：应用到仓库匹配, 保留最近推送的3个 artifacts基于条件tags匹配基于条件 无 Tag
• 推荐定时清理：自定义 cron : 0 0 0 1 */1 * (秒，分，时，日，月，周)
• 镜像是否被签名，漏洞的等级，也可以设置成为镜像安全策略之一，这样可以保证签名过的镜像或者漏洞等级低的镜像才可以被拉取。

整合后的整体流程

​ 通过上面流程图可以看到，整个搭载配置的过程，用户可以自定义镜像源进行拉取镜像，经过Rainbond平台自动推送到Harbor镜像仓库里面，然后等镜像扫描完成以后在进行自动拉取，自动进行构建容器实例。

---

Rainbond 是完全开源的企业级，面向应用的云原生 DevOps， 开发、测试、生产运维一体化平台，不要求开发者掌握容器、Kubernetes 等复杂能力，面向开发者友好；提供从源码或简单镜像持续构建云原生应用的能力，对源码无侵入，业务持续发布到云端；高效的自动化运维，帮助开发者高效管理高可用的、安全的且去中心化的业务系统。

“做好开源客服系统” 

春松客服是拥有坐席管理、渠道管理、机器人客服、数据分析、CRM 等功能于一身的新一代客服系统。将智能机器人与人工客服完美融合，同时整合了多种渠道，结合 CRM 系统，为客户打标签，建立客户的人群画像等，帮助企业向客户提供更加专业客服服务。

客服系统是企业的重要工具，尤其是移动互联网时代，微信公众号、移动电话或是 Facebook Messenger 等渠道分散了企业的服务渠道，企业需要响应来自任何地点任何时间的客户。同时，企业的口碑至关重要，企业服务需要在客户获得、客户激活、客户留存等阶段无懈可击。

春松客服提供多个开箱即用的供企业免费使用的模块：

• 账号及组织机构管理：按组织、角色分配账号权限
• 坐席监控：设置坐席监控角色的人员可以看到并干预访客会话
• 联系人和客户管理：CRM 模块，管理联系人和客户，细粒度维护客户信息，自定义标签和打标签，记录来往历史等
• 网页聊天组件：一分钟接入对话窗口，支持技能组、邀请和关联联系人等
• 坐席工作台：汇聚多渠道访客请求，坐席根据策略自动分配，自动弹屏，转接等
• 机器人客服：与Chatopera 云服务集成，通过插件形式安装，插件也以开源形式提供，查看插件源码。
• 企业聊天：支持企业员工在春松客服系统中群聊和私聊
• 质检：历史会话、服务小结、服务反馈及相关报表

为了使Rainbond的用户能够快速的体验春松客服，我们在Rainbond上制作了春松客服应用并将其发布至Rainbond开源应用商店。

在开源应用商店中搜索 春松客服 应用进行一键部署。

部署完成后的效果图：

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

使用 Rainbond 作为智慧城市底座之后，给我们带来了成倍的运维效率提升。 —— 咸阳市大数据管理局 熊礼智

咸阳市大数据管理局负责全市信息共享工作的组织领导，协调解决与政府信息共享有关的重大问题，研究拟订并组织实施全市大数据战略、规划和政策措施，引导和推动大数据研究和应用工作，建立全市统一的数据服务中心和信息共享机制。通过“端-边-网-云-智” 的全新技术架构，实现管理高效、服务便民、产业发展、生态和谐的目标效用，达成新一代信息技术与城市现代化深度融合，迭代演进的新模式、新理念。

智慧城市的建设中，对智慧城市应用的管理是个很基础的问题。传统的情况下，服务于民生的各类应用系统，都是由相应的政府部门各自部署管辖，这造成了一些困扰。各个城市部门往往各自为政，彼此之间形成数据孤岛，很难互通互联。无论是数据还是应用，都很难统一管理起来。

在咸阳智慧城市建设工作中重点建设数据交换共享平台和应用管理平台。数据交换共享平台负责打通城市各个部门的数据孤岛，进行数据清理和规约之后，最后达成所有城市部门的 IT 应用之间互联互通的效果。

在建设咸阳市智慧城市期间，我们在智慧城市应用管理领域遭遇了很多棘手的问题。为了解决这些痛点，我们借助 Rainbond 这款产品，建设起了可以提供自动化运维能力的应用管理平台。我从四个部分分享解决难题的整个过程：

痛点：回顾智慧城市应用，在部署实施以及后期运维上的难点痛点。

定位：我们如何定位智慧城市应用管理平台，以及希望通过它解决什么样的问题。

落地：简要阐述智慧城市应用管理平台的选型过程，以及部署落地的过程。

实战：讲一个真实的案例，来说明引入应用管理平台后，快速开发落地一个智慧城市应用的全过程。

传统模式下的痛点

我将痛点归纳如下：

• 缺乏统一管理：以往各个城市部门的应用系统的部署是杂乱无章的。每家单位都在建设自己的 IT 系统，没有统一的管理可言。

• 遗留系统多：很多城市部门的应用系统使用的时间都很久了，有的系统甚至已经失去了厂家的支持。而有的系统采用的技术已经过时，无法方便的迁移到可以被集中管理的环境中去，也没有办法很好的将它们监控起来，获得其实时的状态。

• 资源分配不合理：每家单位都在进行 IT 系统的建设，这必然导致做了很多重复性的建设工作，资源浪费随之而来。而且在缺乏资源监控的情况下，没有谁能说清楚各自的应用系统到底应该使用多少资源。访问量不论多少，都分配了同样的资源，缺乏合理性。

• 运维困难：每家单位建设 IT 系统的方式方法五花八门。而这些单位自身往往缺乏相应的技术人才来维护这些系统，一旦出了问题，每套业务系统的维护方式都不一样。

• 缺乏可观测性：以往的 IT 系统建设，往往仅仅关注应用程序本身，而忽略了可观测性的建设。无法做到问题快速发现，往往 IT 系统的失灵，是由用户反馈而来的。

对应用管理平台的定位

应用管理平台负责承载和管理所有智慧城市下属的应用系统，包括新建设起来的数据交换共享平台。后续所有新开发的智慧城市应用会直接基于应用管理平台部署，以往老旧的遗留系统也会随着迭代更新不断迁移到应用管理平台。这么做的目的就是为了能够逐步整合各个城市部门的数据与应用，统一管理。

建设智慧城市的过程中，必然会不断涌现出大批新的城市部门应用系统，如何在建设过程中不重走老路很重要。智慧城市应用管理平台在这个过程中扮演的角色是GPaaS 平台，数据交换共享平台是VPaaS 的一部分。二者相结合，可以将海量城市数据在云端实现汇集融通计算，在提高城市智慧体运行速度的同时也大大降低了运行成本。我将应用管理平台和数据交换共享平台的定位总结如下：

• 应用管理平台向下统一纳管所有计算资源。实现计算资源统一分配调度。这些计算资源以多个机房内托管的虚拟机或者物理机的形式提供。应用管理平台应提供资源监控面板，并在底层计算资源出现问题时发送报警信息。

• 应用管理平台向上承载包括数据交换共享平台在内的所有智慧城市应用系统。提供统一风格的管理面板，以及丰富的自动化运维能力，最大程度降低应用运维管理的难度。智慧城市应用可以以极低的代价迁移到应用管理平台上来，能够实时统计应用的访问流量和资源占用情况，实现计算资源面向应用按需分配，自动调整。

• 应用管理平台横向延伸到各个城市部门。数据交换共享平台需要借助应用管理平台的这一能力，与城市部门现有 IT 系统接驳。

• 应用管理平台可以接纳老旧遗留系统。对于无法直接迁移到应用管理平台的各类老旧遗留系统，比如 Windows 应用等，应可以至少做到逻辑层面的接入，能够以统一风格的面板进行简单管理，以及健康检测等监控能力。

落地过程与价值体现

我们选型并对比了多款 PaaS 平台类产品，最终选择了 Rainbond 。回顾当时的选型过程，以及系统建成到现在的使用体验，我将其优势总结如下：

• 易用性好：Rainbond 是多家选型产品中，易用性做的最好的一款产品。一站式的产品化体验让我们在智慧城市应用的开发部署，乃至后期的运行维护工作中都大大降低了学习成本。数据交换共享平台这个核心应用，仅用不到一周的时间，就完成了向云端的迁移。

• 强大的自动化运维能力：在运维管理方面，其自动化运维能力非常优秀，节省了大量运维成本，使运维效率成倍提升。

• 可观测性：Rainbond 提供了全面的监控报警系统，无论是计算资源还是上层的应用系统，一旦出现问题都可以很快暴露出来。结合自动化运维能力，问题应用系统可以做到自愈自恢复。而通过观察应用系统访问量和资源消耗情况，可以更合理的进行资源分配工作。

• 开源生态：Rainbond 本身是个开源产品，也拥抱开源社区生态。其内部的应用商店系统，提供了大量我们需要的第三方中间件，这些中间件可以一键部署到应用管理平台上去，这节约了大量的时间和精力。否则基于服务器从零搭建这些中间件系统非常耗时耗力。

基于 Rainbond 建设的应用管理平台于 2019年11月落地交付使用。这套应用管理平台底层对接了3个不同的集群，分别是开发测试环境、普通生产环境和涉密生产环境。时至今日，其上部署的各类城市应用已经超过了 100 套，组件数量超过500个。

最先被迁移到应用管理平台上的数据交换共享平台。向开发测试环境迁移的过程比较轻松，我们投入了两名开发人员、两名运维人员，在好雨科技交付工程师的配合下，基于源代码就将所有的组件部署到了应用管理平台上。所有的学习和迁移工作只持续了一周左右就完成了。接下来要考虑的，是在生产环境中部署这套应用系统。我们在这里借助了 Rainbond 内部组件库提供的能力，将开发测试环境中的数据交换共享平台，发布到了内部组件库中，在生产环境中就可以一键部署了。后续的升级操作也都借由应用模版配套的版本管理功能完成，这极大的节约了部署升级成本。

数据交换共享平台需要借助平台能力，延伸到各个城市部门接驳其已有的 IT 系统。最开始 Rainbond 并不支持这个特殊的需求，最终定制了特制的网关，使数据交换共享平台可以通过网关和城市部门已有的 IT 系统交互。

数据交换共享平台部署形态：

在应用的运维管理方面，最让我们觉得好用的，是 Rainbond 提供的统一网关配置功能。通过非常简单的配置，就可以将平台上部署的应用系统对外暴露服务地址。而且经过了定制，我们使用的 Rainbond 网关支持了国密证书，使得我们在安可方面的要求也得到了满足。

经过长时间的考验，基于 Rainbond 建设的应用管理平台的稳定性得到了肯定。尤其是在2020年新冠疫情爆发时，短时间开发部署的外来人口统计系统，也在应用管理平台的支持下，经受住了大并发考验，完成了统计任务。

实战应对疫情考验

2020年2月，由于复工返岗高峰的到来，大规模的人口流动重新启动，为遏制疫情蔓延扩散，做好外来返工人员的防控和服务工作，咸阳市需要用最短的时候完成咸阳市外来人口登记系统的开发和上线，并在3天内完成整个咸阳市130万人信息上报和管控服务。

咸阳市外来人口登记业务是一个前后端分离的业务系统。主要包含了前端页面、后台服务、缓存、数据库、短信业务5个服务组件。

此时，应用管理平台已经落地了半年，我们已经能够非常熟练的基于 Rainbond 进行开发和部署，所以业务的开发上线并没有遇到阻碍，我们很快就完成了业务的上线。

Rainbond提供服务组件的伸缩功能，只需要一键，就可以为当前服务组件快速伸缩出多个实例，并且自动提供负载均衡。为了能够让业务流量过大时，可以自动扩展实例数量，我们还设置了基于内存使用率来触发的自动伸缩功能。在运维层面更加自动化。这将大幅度降低单个实例处理业务的压力。

在咸阳市外来人口登记业务的所有组件中，我们为前端页面、后台服务这两个服务组件都伸缩了最多5个实例，这两个服务组件也是经常进行实时更新的组件，基于多个实例，Rainbond提供滚动更新的功能，使业务的升级不会影响到线上的业务运行。

为了更好的监控“咸阳市外来人口登记业务”各个服务组件的压力情况，我们为前端页面、后台服务、数据库分别安装了Rainbond自带的服务实时性能分析插件。业务运行期间，这个插件为我们带来很多的有用信息，多次帮助开发人员发现业务系统的不足之处，使开发人员可以在业务雪崩宕机之前修正代码并上线。

对于前端页面、后台服务这样的基于Http协议提供服务的组件，插件将提供平均响应时间、吞吐率、在线人数三项实时数据，以及最近5分钟耗时URL排行、历史数据等持续性数据。

整个填报期间，4套业务系统平均在线人数保持在4000人以上，峰值达到5000+，经由统一网关负载的总流量超过 20000。

总结和期待

Rainbond 满足了咸阳市大数据管理局对应用管理平台的预期，运行至今非常稳定。但是，当管理应用系统上百套后后，我们对应用整体监控提出更高要求，需要从更高维度了解所有应用系统运行情况，我了解到他们有更高维度的大屏产品，希望在二期建设过程中，能解决这个问题。

关于Rainbond

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

已有上百家企业使用Rainbond管理关键业务场景，涵盖制造、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。

一.离线交付的痛点

在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了防止数据泄露和运行安全考虑，一般情况下网络会采取内外网隔离的策略，以防范不必要的风险，毕竟在安全防护方面，网络物理隔离是网络安全防御最有效的手段，而网络隔离在软件交付过程中，对于外部软件开发厂商来说将会带来一系列的交付难题，也增加大量成本投入。例如：

1. 现场安装部署和验收测试，效率低下

交付过程中需要将应用程序及依赖的所有资源安装到离线客户环境，而客户环境有可能是物理服务器、虚拟机、私有云及K8s容器等各种环境，加上离线环境网络的限制，就会导致离线环境安装和部署效率低下。由于安装配置过程繁复，容易出错，在最终交付环境中需要重新进行验证测试工作，也需要浪费很多时间。如果部署的是微服务架构的应用系统复杂性更高，工作量还会加倍。

2. 离线环境定制开发和产品升级，成本高

定制开发需要开发人员投入，成本本来就高，在离线环境需要根据客户反馈持续迭代，迭代过程产品不断升级，每升级一次就要走一次安装部署和验证测试过程，成本很高。如果有些工作必须驻场开发，成本更高。

3. 网络不通，无法远程运维

交付完成后，应用需要持续运维，保障运行稳定性和功能持续可用，在网络无法联通的情况下，出任何问题都需要安排人员现场支持，甚至需要安排人员长期驻场。

二.技术选型

上述问题的根本原因是因为，应用系统的多环境适配、应用安装部署、应用升级、应用运维等操作自动化程度不高，需要大量人员手工操作，所以效率很低，解决问题的重点在解决应用管理的自动化。 当前，云原生技术已经越来越成熟，而云原生技术主要解决的就是应用管理的自动化问题，具体有两种开源实现方案 ： 1. Rancher+Helm

Rancher是一款K8s管理工具，他提供K8s的管理UI，包管理使用Helm。对应离线交付的问题，Rancher可以安装在多种运行环境（物理服务器、虚拟机、私有云），并且提供部分应用自动化运维功能，它可以解决 多环境适配和 应用运维问题，而 应用安装部署和 应用升级问题可以通过Helm包解决。

2. Rainbond+应用模版

Rainbond是“以应用为中心”的应用管理平台，应用模版是Rainbond对应用打包的方案，Rainbond提供应用的全生命周期管理（应用开发、应用编排、应用交付和应用运维）。Rainbond可以部署到各种运行环境上（物理服务器、虚拟机、私有云），还可以部署到已有K8s集群和Ranchar上，解决客户多环境适配问题；Rainbond提供应用运维面板解决应用运维问题，使用比较简单，不需要懂容器概念；Rainbond的应用模版是一个亮点，只要在Rainbond上运行起来的应用就可以一键发布成应用模版，简化了应用模版的制作，而且应用模版可以导出离线包，特别适合离线环境的 应用安装部署和 应用升级。

下面分别比较一下两个方案

Rainbond相比Rancher最大的优点就是易用性，不需要学习K8s和容器相关技术和概念，另外，Rainbond提供的一体化开发环境和模块编排功能，能大幅度提高定制开发的效率。Rancher最大的优点是完全兼容K8s体系，如果了解K8s能很快上手。

Helm和应用模版比较

对比项	Helm	应用模板
安装和升级	少量配置	全自动
制作流程	人工编写	全自动
导出和导入离线包	不支持	支持
配置调整	支持预定义的配置调整	支持
模块定制	不支持	支持
兼容其他K8s版本	兼容	需要预先安装Rainbond

Rainbond的应用模版 跟 OAM的设计思路完全一致，“以应用为中心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。

综合对比，在离线交付场景Rainbond+应用模版的方案优势明显，下面我们结合实际例子，来讲解Rainbond+应用模版交付离线客户的整个过程。

三.使用Rainbond应用模版进行离线环境的应用交付

基于Rainbond进行离线环境的应用交付，只需将开发环境已开发好的业务发布至应用市场，基于应用市场导出应用模板的离线包，在交付环境中进行导入操作，导入后基于应用市场一键安装即可自动运行。

预先准备环境

• 拥有两套Rainbond集群，模拟开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。

• 开发环境安装，参考 在线安装 文档；

• 交付环境安装，参考 离线安装 文档；

• 拥有U盘、光盘等离线环境下应用模板离线包传输介质。

1.业务部署 整个流程始于开发环境，我们首先需要将业务搬迁至Rainbond之上。在开发环境基于部署自己的业务，可以支持源代码或是镜像。当前以Spring Cloud微服务框架 Pig 为例，部署参考SpringCloud Pig 在Rainbond部署及应用制作。

2.应用发布

将开发测试环境已开发完成的应用发布至内部组件库：点击应用左侧导航栏 发布 按钮，选择 发布到组件库 ，该过程需要 新建应用模板，应用模板定义了以下信息:

选项名	说明
名称	定义应用名称（必填）
发布范围	应用模板的可见范围，当前团队为当前团队可见，企业所有团队可见（必选）
分类标签	应用标签，可按照架构、行业、部署方式进行分类
简介	应用描述，帮助使用者了解此应用
Logo	应用的Logo图片

创建应用模板后定义应用发布版本：

选项名	说明
版本号	当同应用多次发布时，如果版本号相同，则会覆盖已发布的版本，如果不同，将发布为新版本，应用升级或回滚时，平台根据版本判断（必填）
版本别名	应用别名，例如 高级版，初级版
版本说明	当前发布版本的说明，可区分不同版本的功能差异等信息

发布组件模型配置：

选项名	说明
连接信息	当连接信息中出现密码类的信息，可选择每次部署时自动生成随机值
环境变量	编辑该组件默认的环境变量
伸缩规则	定义该组件可伸缩的最大最小节点数，及节点伸缩步长，最小安装内存限制。

发布插件模型信息：

要发布的应用中其组件携带有插件时，会进行展示并在发布过程中跟随组件发布。

所有信息配置完毕后，点击发布按钮进行发布，业务开发过程中定义的组件间依赖关系、环境配置、持久化存储、插件、运行环境及上述定义的所有信息都将会被打包发布。

3.应用导出

将应用模板进行本地化导出，在首页应用市场中找到已发布的应用，点击最后方扩展按钮，选择导出应用模板，选择应用版本后点击应用模板规范下的导出按钮，导出过程完全自动化，待导出完成后点击下载按钮即可将应用模板下载至本地，保存至U盘等移动存储设备中，带到离线交付环境中去。

接下来进入离线交付流程，交付人员携带着装有离线包的U盘等移动存储设备，开始导入应用模版。

4.应用导入

使用已导出的应用模板在交付环境中导入，点击应用市场界面的离线导入按钮，选择本地的应用模板上传，上传完毕后选择导入范围： 企业或团队，企业为当前交付环境所有人可见，团队为指定团队下的人员可见；点击确认导入即进入自动化导入步骤。

5.一键部署

应用导入后点击安装按钮在当前交付环境即可一键部署该业务系统，该环境业务运行环境与开发环境完全一致，到此完成离线环境下的软件交付。

6.增量升级

软件在更新迭代过程中需要进行某些模块的升级，进行此类升级时即可使用增量升级来节省发布及导入导出时间。

要达成增量升级的效果，需要重新进行应用发布操作，选择之前已创建的应用模板，修改版本号，如之前版本设置为2.9，则此次发布设置为3.0。

在应用发布步骤选择需要进行升级的组件进行发布，而不需要选择所有组件。发布完成后，导出新版本的应用模版离线包，在交付环境中再次导入。

交付环境导入后，平台会对应用模板不同版本进行对比，并通过应用拓扑图中的待升级选项提示用户进行升级。展示版本间属性变更情况，用户选择需要升级的版本进行升级即可，平台将自动执行升级操作，变更组件构建版本。

升级过程中不会变动环境配置类信息，这类信息需要人为改动才会生效：

• 环境变量的值

• 配置文件的内容

• 持久化存储

7.一键回滚

在升级版本上线后出现异常情况需要回滚时，平台提供了一键回滚功能，在升级记录界面选择对应记录点击回滚按钮即可对升级操作进行回滚。

在回滚的过程中，新增组件并不会被删除，如需变更，需要人为操作。

8.应用运维功能

软件产品交付完成以后需要进行长期的运维，在运维层面，交付人员需要考虑服务的可用性、可伸缩性、资源监控，Rainbond提供了诸多运维功能，例如：

• 服务性能分析

  通过Rainbond插件机制扩展性能分析功能，服务实时性能分析插件运行在目标分析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务本身的工作流程和性能无影响，收集服务的平均响应时间，吞吐率等主要指标。

• 资源监控报警

  基于 Prometheus 对平台及业务进行监控，基于 ETCD动态发现 需要监控的 targets，自动配置与管理 Prometheus 服务。

• 实例伸缩

  对服务组件进行垂直伸缩或水平伸缩，在流量高峰期灵活进行扩容。

• 网关管理

  应用网关支持灰度发布和A/B测试功能。

四.场景拓展

上面的例子主要针对常见的离线软件交付场景，但在真实的离线交付场景中，还可能存在以下场景，如：

• 离线模块定制，每个客户交付的模块不一定，根据需要在客户现场开启或关闭模块，或者模块编排。

• 离线定制开发，在离线场景下进行完整的软件开发过程，包括源码管理、源码编译、开发测试环境管理、团队协作、版本发布流程等。

上面两个功能定制场景，通过Rainbond也可以支持，大家可先自行探索。或者关注公众号「好雨云」，后续会发布上述场景的详细教程。

五.总结

本文我们分析了离线交付场景的问题，对比了可能的技术方案，并使用一个例子完整讲解离线交付全过程，整个过程自动化程度很高。使用Rainbond进行离线交付肯定可以提高效率，但到底在哪些方面提高我们的效率，我再总结一下：

• 离线环境应用系统一键导出和导入

  交付过程中只需要携带基于Rainbond导出的应用模板离线包在交付环境进行导入，即可一键安装整套业务系统。

• 开发环境和离线环境完全一致

  Rainbond屏蔽了底层环境的差异，基于应用模板进行交付，模板对应用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不需要进行重复性测试。

• 一体化客户定制环境

  软件交付过程中，不同的客户会有不同的定制需求，也就意味着需要为不同客户开发不同的模块，这些定制的模块在不同项目中都不尽相同，通过Rainbond提供的应用编排，就可以针对不同客户编排和开启不同功能模块；如果需要定制开发，就可基于交付环境已部署的Rainbond直接进行离线代码开发工作，包括源码编译、配置组件运行环境等，在交付环境中完成所有定制工作。

• 离线环境客户持续交付

  对于项目实施团队而言，在实施过程中需要不断将 新功能、缺陷修复 等快速落实到交付环境或用户手中，传统的持续交付过程中，离线环境下需要交付人员驻场，手动执行更新上线操作，该过程不仅增加了交付时间，且长期的手动执行操作会增加部署的风险；而Rainbond的持续交付能力，能够实现应用后续的增量导入、导出和版本升级，能够带来以下优势:

  • 通过自动化方式实现，有效缩短代码提交到部署上线的时间。

  • 软件在整个生命周期内都处于可部署升级的状态。

  • 简化升级步骤，使软件版本更加清晰。

  • 让交付过程成为可预期的、可视化的过程。

• 离线环境下自动化运维

  服务高可用，自容错和自恢复机制，减少人工运维，提高业务系统稳定性。

六.关于Rainbond

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

已有上百家企业使用Rainbond管理关键业务场景，涵盖制造、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。