云原生应用程序的架构应该怎么设计？.docxVIP

云原生应用程序的架构应当怎样设计？ 云原生是一种将应用程序构建为微服务并在容器化和动态编排平台上进行运转的方法，这些平台充分利用了云计算模型的优势。云原生关注的是如何创建和部署应用程序，而不是在哪里运转。这些技术使组织能够在现代的动态环境（如公有云、私有云和混合云）中构建和运转可扩展的应用程序。这些应用程序是从头开头构建的，设计为松散耦合系统，针对云规模和功能进行了优化，使用托管服务并利用持续交付来实现牢靠性和更快的上市时间。总体目标是提高速度、可扩展性和提高利润率。 速度。各种规模的公司现在都看到了一个战略优势，即能够快速举动并快速将创意推向市场。通过这种方式，意味着以前需要几个月时间才能将想法转化为生产，现在则变成了数天甚至数小时。这一目标的实现部分是由于企业内部的文化转变，从大爆炸项目转变为更多的渐进式改进。从本质上讲，Cloud Native 策略是关于处理技术风险的。过去，我们避开危急的标准方法是缓慢而谨慎地举动。Cloud Native 方法则是通过实行小型、可逆和低风险的步骤来快速实现。 可扩展性。随着企业的进展，战略上必需在更多地点为更多用户供应更广泛的设备支持，同时保持响应力量，管理成本而不会失败。 利润。在云基础设备的新世界中，战略目标是仅在需要时为新客户上线领取额外资源。消费从前期 CAPEX（购买新机器以预期成功）转移到 OPEX（按需领取额外服务器）。 CNCF 的角色 云原生计算基金会是一个开源软件基金会，归属于 Linux 基金会，包括谷歌、IBM、英特尔、Box、思科和 VMware 等大公司，努力于使云原生计算具有普遍性和可持续性。云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到本人的容器中，并动态编排这些容器以优化资源利用率。 “为什么需要 CNCF “的常见 QA： 公司意识到他们需要成为一家软件公司，即便他们没有软件业务。例如，Airbnb 正在转变酒店业，并且更多传统酒店正在努力竞争。 云原生允许 IT 和软件更快地移动。 接受云原生技术和实践使公司能够在内部创建软件，使业务人员能够与 IT 人员亲密合作，不落后于竞争对手，并为客户供应更好的服务。 云原生设计准绳 设计为松散耦合的微服务 微服务是一种将单个应用程序开发为一套小型服务的方法，每个小型服务都在本人的进程中运转，并使用 HTTP 等轻量级协议进行通信。这些服务围绕业务功能构建，可通过全自动部署机制独立部署。 使用最佳言语和框架开发 云原生应用程序的每个服务都是使用最适合该功能的言语和框架开发的。云原生应用程序是多言语的。服务使用各种言语、运转时和框架。例如，开发人员可以使用 Node.js 开发基于 WebSocket 的实时流服务，同时选择 Python 来构建机器学习基础服务，并选择 spring-boot 来暴露 REST API。开发微服务的最佳方式是为特定工作选择最佳言语和框架。 以互动和协作为中心的 API 云原生服务使用轻量级 API，这些 API 基于表述性形态转移（REST）等协议来公开其功能。内部服务使用 Thrift、Protobuff、GRPC 等二进制协议相互通信，以获得更好的功能。 无形态且可大规模扩展 云原生应用程序将其形态存储在数据库或其他外部实体中，因而实例可以弹性伸缩。任一实例都可以处理恳求。它们与底层基础架构无关，后者允许应用程序以高度分布的方式运转，并且仍旧保持其形态，而与底层基础架构的弹性机制无关。从可伸缩性的角度来看，架构就像向集群添加商品服务器节点一样简约，能够扩展应用程序。 健壮性作为架构核心 依据墨菲定律 - “凡是可能出错的事就肯定会出错”。当我们将其应用于软件系统时，在分布式系统中，毛病会发生。硬件可能会失败。网络可能会消灭瞬态毛病。甚至整个服务或地区可能会消灭中缀，但即便是这样也必需进行规划。健壮性是指系统从毛病中恢复并连续运转的力量。它不是避开毛病，而是以避开停机和数据丢失的方式响应毛病。健壮性的目标是在发生毛病后将应用程序恢复到完全正常运转的形态。健壮性供应以下内容： 高可用性 - 应用程序在健康形态下连续运转的力量，无需大量停机 灾难恢复 - 应用程序从稀有但严重大事中恢复的力量：非瞬态、大规模毛病，例如影响整个区域的服务中缀 使应用程序更健壮的次要方法之一是通过冗余。HA 和 DR 使用多节点集群、多区域部署、数据复制、无单点毛病、持续监控等实现。 以下是实现健壮性的一些策略： 重试瞬态毛病 - 瞬时毛病可能是由于网络连接临时丢失、数据库连接中缀或服务繁忙时超时形成的。通常只需简约重试恳求即可处理瞬时毛病； 跨实例的负载平衡 - 在任何地方实施集群。无形态应用程序应当能够通过向集群添加更多节点来扩展； 优雅降级 - 假如服务失败且没有毛病转移