The world is distributed
分布式世界
Just ask any 'cool kid': Modern, distributed systems are in, and monolithic apps are out!
随便问一个酷小子，他们都会说：现代、分布式系统时间已经到来，单体应用已经成为过去式！
But, it's not just "cool kids." Progressive IT Leaders, corporate architects, and astute developers are echoing these same thoughts as they explore and evaluate modern distributed applications. Many have bought in. They're designing new and replatforming existing enterprise applications following the principles, patterns, and practices of distributed microservice applications.
但并不只是 "酷小子"。 卓越的IT领袖、企业架构师和精明的开发人员在探索和评估现代分布式应用程序时，会响应这些想法（产生共鸣）。 许多人都认同接受。 他们正在按照分布式微服务应用程序的原理、模式和实践设计新的和重构现有企业应用程序。
But, this evolution raises many questions...
- What exactly is a distributed application?
- Why are they gaining popularity?
- What are the costs?
- And, importantly, what are the tradeoffs?
但是演进引发了许多问题 ...
- 究竟什么是分布式应用程序？
- 为什么他们会获得欢迎？
- 要付出哪些成本（代价）？
- 重要的是，需要做哪些折衷？
To start, let's rewind and look at the past 15 years. During this period, we typically constructed applications as a single, monolithic unit. Figure 1-1 shows the architecture.
首先，让我们回顾一下，看看过去15年。 在此期间，我们通常将应用程序构建成单体应用。 图1-1 显示了此体系结构。
Figure 1-1. Monolithic architecture.
图 1-1。 单体应用体系结构。
Note how the modules for Ordering, Identity, and Marketing execute in a single-server process. Application data is stored in a shared database. Business functionality is exposed via HTML and RESTful interfaces.
注意用于订单、标识和营销的模块在单服务器进程中的执行方式。 应用程序数据存储在共享数据库中。 业务功能通过 HTML 和 RESTful 接口公开。
In many ways, monolithic apps are straightforward. They're straightforward to:
- Build
- Test
- Deploy
- Troubleshoot
- Scale vertically (scale up)
在许多方面，单体应用程序简单明了。 它们能直截了当地：
- 构建
- 测试
- 部署
- 疑难解答
- 垂直缩放 (向上扩展)
However, monolithic architectures can present significant challenges.
但单体结构可能会带来重大挑战。
Over time, you may reach a point where you begin to lose control...
- The monolith has become so overwhelmingly complicated that no single person understands it.
- You fear making changes as each brings unintended and costly side effects.
- New features/fixes become time-consuming and expensive to implement.
- Even the smallest change requires full deployment of the entire application - expensive and risky.
- One unstable component can crash the entire system.
- Adding new technologies and frameworks aren't an option.
- Implementing agile delivery methodologies are difficult.
- Architectural erosion sets in as the code base deteriorates with never-ending "special cases."
- Eventually the consultants come in and tell you to rewrite it.
随着时间的推移，你可能会在某个时间点开始失控...
- 单体架构已变得非常复杂，没有人能理解（看懂）它。
- 您担心每个更改都会带来意想不到且代价高昂的副作用。
- 新功能/修补程序的实现非常耗时且成本高昂。
- 即使是最小的更改，也需要完全部署整个应用程序-成本高昂且风险巨大。
- 一个不稳定的组件可能会破坏整个系统。
- 添加新的技术和框架不太自由方便。
- 实现敏捷交付非常困难。
- 随着代码库的恶化，体系结构也被腐蚀，充斥着无止境的 "特殊情况"。
- 最终，顾问会介入，并告诉你重构它。
IT practitioners call this condition the Fear Cycle. If you've been in the technology business for any length of time, good chance you've experienced it. It's stressful and exhausts your IT budget. Instead of building new and innovative solutions, most of your budget is spent maintaining legacy apps.
IT 从业人员称此限制条件为 恐怖循环 。 如果你已在技术业务中花费了很长时间，很可能经历过这种情况。 倍感压力并耗尽您的 IT 预算。 大多数预算都用来维护旧应用，而不是构建新的创新性解决方案。
Instead of fear, businesses require speed and agility. They seek an architectural style with which they can rapidly respond to market conditions. They need to instantaneously update and individually scale small areas of a live application.
企业要求速度与灵活性，而不是担心。 他们会寻找一种架构样式，使其能够快速响应市场状况。 他们需要即时更新和单独缩放运行中的应用程序的某一小块。
An early attempt to gain speed and agility came in the form of Service Oriented Architecture, or SOA. In this model, service consumers and service providers collaborated via middleware messaging components, often referred to as an Enterprise Service Bus, or ESB. Figure 1-2 shows the architecture.
最早在 面向服务的体系结构或 SOA 的基础上，尝试获得速度和灵活性。 在此模型中，服务使用者和服务提供者通过中间件消息传送组件进行协作，通常称为 企业服务总线，或 ESB 。 图1-2 显示了此体系结构。
Figure 1-2. SOA architecture.
图 1-2。 SOA 体系结构。
With SOA, centralized service providers registered with the ESB. Business logic would be built into the ESB to integrate providers and consumers. Service consumers could then find and communicate with these providers using the ESB.
对于 SOA，集中式服务提供者向 ESB 注册。 将业务逻辑内置于 ESB 中以集成提供者和使用者。 然后，服务使用者可以使用 ESB 查找这些提供者并与其通信。
Despite the promises of SOA, implementing this approach often increased complexity and introduced bottlenecks. Maintenance costs became high and ESB middleware expensive. Services tended to be large. They often shared dependencies and data storage. In the end, SOAs often resulted in a 'distributed monolithic' structure with centralized services that were resistant to change.
尽管有 SOA 的保证，但实现此途径通常会增加复杂性并引入瓶颈。 维护成本变得很高，ESB 中间件价格高昂。 服务越来越庞大。 它们通常共享依赖和数据存储。 最终，Soa 通常会导致集中服务的 "分布式单体" 结构，这些服务很难更改。
Nowadays, many organizations have realized speed and agility by adopting a distributed microservice architectural approach to building systems. Figure 1-3 shows the same system built using distributed techniques and practices.
如今，许多组织通过采用分布式微服务体系结构方法构建系统来实现速度和灵活性。 图1-3 显示了使用分布式技术和实践构建的同一系统。
Figure 1-3. Distributed architecture.
图 1-3。 分布式体系结构。
Note how the same application is decomposed across a set of distributed services. Each is self-contained and encapsulates its own code, data, and dependencies. Each is deployed in a software container and managed by a container orchestrator. Instead of a single database shared by multiple services, each service owns a private database. Other services can't access this database directly and can only get to data that is exposed through the public API of the service that owns it. Note how some services require a full relational database, but others, a NoSQL datastore. The basket service stores its state in a distributed key/value cache. Note how inbound traffic routes through an API Gateway service. It's responsible for directing calls to services and enforcing cross-cutting concerns. Most importantly, the application takes full advantage of the scalability, availability, and resiliency features found in modern cloud platforms.
注意如何将同一应用分解为一系列分布式服务。 每个服务都是自包含的，并封装自己的代码、数据和依赖项。 每个服务部署在软件容器中并由容器编排器管理。 每个服务都拥有一个专用数据库，而不是由多个服务共享的单个数据库。 其他服务不能直接访问此数据库，只能通过拥有它的服务的公共 API 获取数据。 请注意，某些服务需要关系数据库，而另一些服务则需要 NoSQL 数据存储。 购物篮服务将其状态存储在分布式键/值缓存中。 请注意入站通讯如何通过 API 网关服务路由。 API网关负责将调用定向到服务并强制横切关注点。 最重要的是，应用程序充分利用了现代云平台中的可扩展性、可用性和弹性特征。
But, while distributed services can provide agility and speed, they present a different set of challenges. Consider the following...
- How can distributed services discover each other and communicate synchronously?
- How can they implement asynchronous messaging?
- How can they maintain contextual information across a transaction?
- How can they become resilient to failure?
- How can they scale to meet fluctuating demand?
- How are they monitored and observed?
但是，尽管分布式服务可提供灵活性和速度，但它们却引入了不同的挑战。 请考虑以下事项...
- 分布式服务如何相互发现并进行同步通信？
- 如何实现异步消息传送？
- 如何在事务中维护上下文信息？
- 如何才能灵活应对故障？
- 如何缩放以满足不断变化的需求？
- 如何监视和观察它们？
For each of these challenges, multiple products are often available. But, shielding your application from product differences and keeping code maintainable and portable become a challenge.
对于上述每种挑战，多种产品可供使用。 但是，保护应用程序不受产品差异影响，保持代码的可维护性和可移植性将成为一项挑战。
This book introduces Dapr. Dapr is a distributed application runtime. It directly addresses many of the challenges found that come along with distributed applications. Looking ahead, Dapr has the potential to have a profound impact on distributed application development.
本书介绍了 Dapr。 Dapr 是分布式应用程序运行时。 它直接解决了分布式应用程序附带的许多挑战。 展望未来，Dapr 有可能对分布式应用程序开发产生深远影响。
Summary
总结
In this chapter, we discussed the adoption of distributed applications. We contrasted a monolithic system approach with that of distributed services. We pointed out many of the common challenges when considering a distributed approach.
在本章中，我们讨论了分布式应用程序的采用。 我们对比了单体系统模式与分布式服务模式。 考虑分布式模式时，我们指出了许多常见的难题。
Now, sit back, relax, and let us introduce you the new world of Dapr.
现在，坐下来，放松，让我们向您介绍Dapr的新世界。
