翻译：多运行时微服务架构

这样文章通过Google翻译和人工逐字修改的方式完成的，某些位置也加上自己的理解。如有错误，请指出。 翻译这篇文章的目的其实是为了自己加深对微服务、分布式架构以及多运行时架构的理解。整篇文章从”战略“上分析了微服务”从古至今“解决的问题，以及带来的新问题；进而在“战术”层面，给出了解决这些新问题的手段。 个人见解：架构从来都是解决问题并带来问题， 取舍之道 。 背景知识 微服务的 12 要素： 基准代码：一份基准代码，多份部署 依赖：显式声明依赖关系 配置：在环境中存储配置 后端服务：把后端服务当做附加资源 构建、发布、运行：严格分离构建和运行 进程：以一个或多个无状态进程运行应用 端口绑定：通过端口绑定提供服务 并发：通过进程模型进行扩展 易处理：快速启动和优雅终止可最大化健壮性 开发环境与线上环境等价：尽可能的保持开发、预发布、线上环境相同 日志：把日志当做事件流 管理进程：后台管理任务当做一次性进程运行 原文从此处开始： 创建分布式系统并非易事。围绕“微服务”架构和“ 12要素应用程序”设计出现了最佳实践。这些提供了与交付生命周期，网络，状态管理以及对外部依赖项的绑定有关的准则。 但是，以可扩展和可维护的方式一致地实施这些原则是具有挑战性的。 解决这些原理的以技术为中心的传统方法包括企业服务总线（ESB）和面向消息的中间件（MOM）。虽然这些解决方案提供了良好的功能集，但主要的挑战是整体架构以及业务逻辑和平台之间的紧密技术耦合。 随着云，容器和容器协调器（Kubernetes）的流行，出现了解决这些原理的新解决方案。例如，Knative用于交付，服务网格用于网络，而Camel-K用于绑定和集成。 通过这种方法，业务逻辑（称为“微逻辑”）构成了应用程序的核心，并且可以创建提供强大的现成分布式原语的sidecar“ mecha”组件。 微观组件和机械组件的这种分离可以改善第二天的操作，例如打补丁和升级，并有助于维持业务逻辑内聚单元的长期可维护性。 创建良好的分布式应用程序并非易事：此类系统通常遵循12要素应用程序和微服务原则。它们必须是无状态的，可伸缩的，可配置的，独立发布的，容器化的，可自动化的，并且有时是事件驱动的和无服务器的。创建后，它们应该易于升级，并且长期可以承受。在当今的技术中，要在这些相互竞争的要求之间找到良好的平衡仍然是一项艰巨的努力。 在本文中，我将探讨分布式平台如何发展以实现这种平衡，更重要的是，在分布式系统的演进中还需要发生什么事情，以简化可维护的分布式体系结构的创建。如果您想让我实时谈论这个话题，请加入我的QCon 三月的伦敦。 分布式应用程序需求 在此讨论中，我将把现代分布式应用程序的需求分为四个类别-生命周期，网络，状态，绑定-并简要分析它们在最近几年中的发展情况。 生命周期 Lifecycle 打包 Packaging 健康检查 Healthcheck 部署 Deployment 扩展 Scaling 配置 Configuration 让我们从基础开始。当我们编写一项功能时，编程语言将指示生态系统中的可用库，打包格式和运行时。例如，Java使用.