【IT168 编译】通过在微服务上构建分布式应用，可以提供一种很好的方式来运行云原生应用程序。这种分布式应用程序架构为企业带来了更大的优势——改进对性能的控制、高可用性、更好的灾难恢复和更深层次的可见性——但基于微服务构建的分布式应用远比传统应用复杂，因此这种构建可以说既是一门艺术，也是一门科学。
容器技术实现地理分布
传统应用程序往往与它们的底层基础设施紧密相连。现代容器技术改变了这种关系，因为它能够通过将基础设施层从应用程序代码中抽象出来，让同一个应用程序可以在任何类型的基础设施上运行。这种转变开创了多云或混合云模式的时代。应用程序可移植性是吸引开发人员使用容器的第一个原因，也是容器技术在支持分布式微服务方面的一个显著特性。
地理分布的应用程序有各种形状和大小。你可以集中应用程序的某些方面，并将其他方面进行分布。进行地理分布时，你必须考虑云供应商的可用区域。除了云供应商的数据中心之外，你还可以将数据存储在你自己的数据中心，可以在本地或远程管理这些数据中心。除了硬件的物理位置之外，开发团队和最终用户的位置也有助于确定应用程序性能。因此，选择一个离应用程序用户最近的物理位置非常重要。
像Kubernetes这样的容器编排工具，能够将在分布式环境中运行应用程序所需的所有组件组合在一起。Kubernetes可用于管理任何云供应商上的云实例，它将容器实例抽象为一组Pod，使基础设施易于管理，更适合分布式应用程序。
在Kubernetes中，每个Pod都应该有一个副本Pod，作为主Pod的备份。每个Kubernetes部署的副本数量是使用ReplicaSet自动控制的。副本还有助于提高在流量高峰期的水平可伸缩性。
管理网络作为一个单独的层
容器网络近年来日趋成熟，最大的一点是我们现在可以将存储和网络等视为与应用程序层和基础结构层分离的层。有一些功能强大的Kubernetes网络工具，如Istio、Linkerd和gRPC，都可以用于改善负载平衡、服务发现和其他关键网络进程。
服务连接工具gRPC使用HTTP/2协议，支持多个双向流调用。在一个地理分布的微服务应用程序中，网络调用的数量必然很高，像gRPC这样的工具提供了能够大规模处理这些调用的渠道。
Kubernetes还以一种对地理分布的微服务应用程序有效的方式处理网络，因为它遵循网络代理的sidecar代理模型。sidecar容器并不独立存在，而是支持Kubernetes Pod中的另一个主容器或另一组容器。它可用于通过日志代理收集日志，或使用网络代理来处理服务到服务(service-to-service)的通信。
在分布式微服务应用程序中，服务到服务的通信量是巨大而复杂的。与其在应用程序代码或应用程序容器中配置所有联网逻辑，不如将它们分离到sidecar容器中。这可以帮助我们在应用程序之外管理它们，甚至可以在未来重用它们，以节省时间。
Latency-aware数据存储
在地理分布的应用程序中，如何管理存储将直接影响应用程序的性能。为了保证应用程序处理请求的速度，访问远程存储数据并保证数据传输速率是非常重要的。
企业应用程序通常会在诸如SAP ERP、Oracle E-Business Suite等系统中容纳数万甚至数百万个数据点。要让应用程序访问和使用这些大型数据集，需要的不仅仅是按指定路线发送(routing)一个请求到正确的数据库。系统必须配置为，在此过程中处理延迟和微故障。
当能够从远程位置获取数据时，配置为最终数据一致性的应用程序会运行得很好。在这个模型中，数据以块的形式获取，当每一块数据到达前端设备时，它可以直接进行加载而不用等待所有的数据块。通过这种操作方式，可以稍后在更新数据本身，使其与后端数据库保持一致，但重点仍然是在处理大型数据集的情况下交付快速的UI。
在移动应用程序中，数据缓存是处理数据访问的一个重要方面。应用程序来回请求数据是低效的，其中一些数据可能会被复制。如果应用程序将部分数据存储在客户机上，那就更好了，因为客户机需要一种一致的方式来处理离线功能的数据缓存。更少的请求可以加速数据传输，并在应用程序中提供更好的用户体验。
使用微服务的地理分布应用程序在今天的云原生环境中很常见。容器技术会有助于这种架构的设置，并帮助用户管理数据交付的各个方面，比如网络和存储，而这些方面与应用程序代码本身是分离的。随着相关技术的进步，基于微服务构建的地理分布应用程序的管理将比以往任何时候都更容易，并且应成为高效的软件交付策略中的一部分。
来源：TechTarget 原文链接：https://searchmicroservices.techtarget.com/tip/How-to-manage-distributed-apps-built-on-microservices
