Dapr-2: 世界是分布式的

第 2 章 世界是分布的

只需要问任何达人：现代的、分布式的系统已经到来，单体应用已经过时。

但是，不仅是达人，渐进的 IT 领袖，企业架构师，以及精明的开发者，在探寻和评估现代分布式应用的时候，也在呼应这些相同的想法。许多已经踏入。遵循这些特性、模式和分布式微服务应用程序的实践，他们正在设计新的，对现存的企业应用程序重平台化。

但是，变革带来很多问题......

• 到底什么是分布式应用？
• 为什么它变得流行？
• 代价是什么？
• 以及，更加重要的，折衷了什么？

为了开始，我们重新回顾过去的 15 年，在这段时间中，我们典型地以单体式构建应用程序。图 1-1 展示了其架构。

注意对于订单、身份和市场模块是如何运行在单个服务器进程中的。应用程序的数据保存在共享的数据库中。业务功能以 HTML 和 RESTful 接口的方式暴露出来。

从很多方面来说，单体应用是简单明了的，它简单在：

• 构建
• 测试
• 部署
• 错误定位
• 纵向扩展

但是，单体架构会遇到明显的挑战

随着时间的演进，你会到达失去控制的一个点：

• 单体应用变得无比复杂，以至于没有一个人可以完全理解它。
• 你害怕做出变更，因为每次都会带来未预期的结果和昂贵的副作用
• 新的特性/补丁在实现的时候变得耗时和代价高昂
• 即使最小的变更也需要完全部署完整的应用程序，代价高昂且高风险
• 单个不稳定的组件可以导致整个系统的崩溃
• 增加新的技术和框架变得不可行
• 难于实施敏捷交付方法论
• 由于代码对于永无尽头的 "特例" 的劣化，导致架构腐化
• 顾问总是告诉你重写系统

IT 实践者称这种情况为恐怖循环。如果你在任何技术公司的时间足够长，你就会有机会体验这一点。充满压力并耗尽你的 IT 预算。没有构建新的和创建方案，你的大多数预算都花费在维护遗留系统上。

与害怕相反，业务需要速度和敏捷。它寻求一种架构风格，可以迅速响应市场的变化。它需要即时更新并可以独立扩展运行的应用程序中的单个小的部分。

早期的达到速度和敏捷的尝试是面向服务的架构，或者说 SOA。在该模型下，服务的消费者和服务的提供者之间，通过中间件消息组件协作。通常称为企业消息总线，或者 ESB。图 1-2 展示了该架构。

对于 SOA，中心化的服务提供者使用 ESB 注册。业务逻辑构建到 ESB 中来集成提供者和消费者。服务消费者随后使用 ESB 来查找，与这些提供者进行通讯。

尽管 SOA 承诺，实现这种方式通常增加了复杂性，引入瓶颈。维护费用变高，ESB 中间件昂贵。服务趋向于更大。他们经常共享依赖和数据存储。最终，SOA 经常导致 "分布式的单体" 结构，使用中心化的服务抵抗变化。

如今，大多数的组织通过适配分布式的微服务架构方式来构建系统，以实现速度和敏捷。图 1-3 展示了使用分布式技术和实践构建的相同系统。

请注意同样的应用程序是如何解构为分布式的服务集合的。每个服务是自包含并封装了自己的代码，依赖。每个服务部署在单个的软件容器中，通过容器的协调器进行改成。与多个服务共享单个数据库相反，每个服务拥有私有的数据库。其它服务不能直接访问该数据库，只能通过该服务暴露的 public API 来获取数据。请注意有些微服务需要完全的关系数据库，但是，其它的是 NoSQL 数据存储。购物车服务在分布式的键值缓存中存储其状态。请注意入站的流量通过 API 网关服务进行路由。它负责对服务的直接访问和强制横切关注点。最重要的是，应用程序获得了现代云平台的扩展性、可用性、弹性的完全优势。

但是，虽然分布式的服务可以提供敏捷和速度，也带来了一系列的挑战，考虑下面列出的这些：

• 分布式的服务如何发现其它服务，它们之间如何实现同步通讯？
• 如何实现异步消息？
• 如何在服务之间实现事务上下文的传递
• 如何在失效的情况下支持弹性服务
• 如何支持动态扩展以支持负载波动
• 如何支持监控和处理过程的可观察

对于这些挑战中的每一个，许多产品都通常是可以提供的。但是，将你的应用程序与产品细节进行隔离，保持代码的可维护性并方便性也成为一个新挑战。

本书介绍 Dapr，Dapr 是分布式应用程序运行时。它直接面对伴随分布式应用程序而来的诸多挑战。展望未来，Dapr 有可能对分布式应用程序的开发产生深远影响。

总结

在本章中，我们讨论了适配分布式应用程序的问题。比较了单体系统方式与分布式服务。在考虑分布式方式的时候，我们指出了许多公共的挑战。

现在，坐下来，放松，让我们向您介绍 Dapr 的新世界。