面向.NET開發(fā)人員的Dapr——前言

The world is distributed

分布式世界

Just ask any 'cool kid':?Modern, distributed systems are in, and monolithic apps are out!

隨便問一個酷小子，他們都會說：現(xiàn)代、分布式系統(tǒng)時間已經(jīng)到來，單體應用已經(jīng)成為過去式！

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領袖、企業(yè)架構(gòu)師和精明的開發(fā)人員在探索和評估現(xiàn)代分布式應用程序時，會響應這些想法（產(chǎn)生共鳴）。許多人都認同接受。他們正在按照分布式微服務應用程序的原理、模式和實踐設計新的和重構(gòu)現(xiàn)有企業(yè)應用程序。

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?

但是演進引發(fā)了許多問題 ...

• 究竟什么是分布式應用程序？

• 為什么他們會獲得歡迎？

• 要付出哪些成本（代價）？

• 重要的是，需要做哪些折衷？

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年。在此期間，我們通常將應用程序構(gòu)建成單體應用。圖1-1 顯示了此體系結(jié)構(gòu)。

Figure 1-1. Monolithic architecture.

圖 1-1。單體應用體系結(jié)構(gòu)。

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.

注意用于訂單、標識和營銷的模塊在單服務器進程中的執(zhí)行方式。應用程序數(shù)據(jù)存儲在共享數(shù)據(jù)庫中。業(yè)務功能通過 HTML 和 RESTful 接口公開。

In many ways, monolithic apps are?straightforward. They're straightforward to:

• Build

• Test

• Deploy

• Troubleshoot

• Scale vertically (scale up)

在許多方面，單體應用程序簡單明了。它們能直截了當?shù)?#xff1a;

• 構(gòu)建

• 測試

• 部署

• 疑難解答

• 垂直縮放 (向上擴展)

However, monolithic architectures can present significant challenges.

但單體結(jié)構(gòu)可能會帶來重大挑戰(zhàn)。

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.

隨著時間的推移，你可能會在某個時間點開始失控...

• 單體架構(gòu)已變得非常復雜，沒有人能理解（看懂）它。

• 您擔心每個更改都會帶來意想不到且代價高昂的副作用。

• 新功能/修補程序的實現(xiàn)非常耗時且成本高昂。

• 即使是最小的更改，也需要完全部署整個應用程序-成本高昂且風險巨大。

• 一個不穩(wěn)定的組件可能會破壞整個系統(tǒng)。

• 添加新的技術(shù)和框架不太自由方便。

• 實現(xiàn)敏捷交付非常困難。

• 隨著代碼庫的惡化，體系結(jié)構(gòu)也被腐蝕，充斥著無止境的 "特殊情況"。

• 最終，顧問會介入，并告訴你重構(gòu)它。

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 從業(yè)人員稱此限制條件為?恐怖循環(huán)?。如果你已在技術(shù)業(yè)務中花費了很長時間，很可能經(jīng)歷過這種情況。倍感壓力并耗盡您的 IT 預算。大多數(shù)預算都用來維護舊應用，而不是構(gòu)建新的創(chuàng)新性解決方案。

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.

企業(yè)要求速度與靈活性，而不是擔心。他們會尋找一種架構(gòu)樣式，使其能夠快速響應市場狀況。他們需要即時更新和單獨縮放運行中的應用程序的某一小塊。

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.

最早在?面向服務的體系結(jié)構(gòu)或?SOA?的基礎上，嘗試獲得速度和靈活性。在此模型中，服務使用者和服務提供者通過中間件消息傳送組件進行協(xié)作，通常稱為?企業(yè)服務總線，或?ESB?。圖1-2 顯示了此體系結(jié)構(gòu)。?

Figure 1-2. SOA architecture.

圖 1-2。SOA 體系結(jié)構(gòu)。

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 注冊。將業(yè)務邏輯內(nèi)置于 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 的保證，但實現(xiàn)此途徑通常會增加復雜性并引入瓶頸。維護成本變得很高，ESB 中間件價格高昂。服務越來越龐大。它們通常共享依賴和數(shù)據(jù)存儲。最終，Soa 通常會導致集中服務的 "分布式單體" 結(jié)構(gòu)，這些服務很難更改。

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.

如今，許多組織通過采用分布式微服務體系結(jié)構(gòu)方法構(gòu)建系統(tǒng)來實現(xiàn)速度和靈活性。圖1-3 顯示了使用分布式技術(shù)和實踐構(gòu)建的同一系統(tǒng)。

Figure 1-3. Distributed architecture.

圖 1-3。分布式體系結(jié)構(gòu)。

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.

注意如何將同一應用分解為一系列分布式服務。每個服務都是自包含的，并封裝自己的代碼、數(shù)據(jù)和依賴項。每個服務部署在軟件容器中并由容器編排器管理。每個服務都擁有一個專用數(shù)據(jù)庫，而不是由多個服務共享的單個數(shù)據(jù)庫。其他服務不能直接訪問此數(shù)據(jù)庫，只能通過擁有它的服務的公共 API 獲取數(shù)據(jù)。請注意，某些服務需要關系數(shù)據(jù)庫，而另一些服務則需要 NoSQL 數(shù)據(jù)存儲。購物籃服務將其狀態(tài)存儲在分布式鍵/值緩存中。請注意入站通訊如何通過 API 網(wǎng)關服務路由。API網(wǎng)關負責將調(diào)用定向到服務并強制橫切關注點。最重要的是，應用程序充分利用了現(xiàn)代云平臺中的可擴展性、可用性和彈性特征。

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?

但是，盡管分布式服務可提供靈活性和速度，但它們卻引入了不同的挑戰(zhàn)。請考慮以下事項...

• 分布式服務如何相互發(fā)現(xiàn)并進行同步通信？

• 如何實現(xiàn)異步消息傳送？

• 如何在事務中維護上下文信息？

• 如何才能靈活應對故障？

• 如何縮放以滿足不斷變化的需求？

• 如何監(jiān)視和觀察它們？

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.

對于上述每種挑戰(zhàn)，多種產(chǎn)品可供使用。但是，保護應用程序不受產(chǎn)品差異影響，保持代碼的可維護性和可移植性將成為一項挑戰(zhàn)。

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 是分布式應用程序運行時。它直接解決了分布式應用程序附帶的許多挑戰(zhàn)。展望未來，Dapr 有可能對分布式應用程序開發(fā)產(chǎn)生深遠影響。

Summary

總結(jié)

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.

在本章中，我們討論了分布式應用程序的采用。我們對比了單體系統(tǒng)模式與分布式服務模式。考慮分布式模式時，我們指出了許多常見的難題。

Now, sit back, relax, and let us introduce you the new world of Dapr.

現(xiàn)在，坐下來，放松，讓我們向您介紹Dapr的新世界。

目錄：

• 面向.NET開發(fā)人員的Dapr——前言

• 面向.NET開發(fā)人員的Dapr——分布式世界

• 面向.NET開發(fā)人員的Dapr——俯瞰Dapr

• 面向.NET開發(fā)人員的Dapr——入門

• 面向.NET開發(fā)人員的Dapr——參考應用程序

• 面向.NET開發(fā)人員的Dapr——狀態(tài)管理

• 面向.NET開發(fā)人員的Dapr——發(fā)布和訂閱

總結(jié)

以上是生活随笔為你收集整理的面向.NET开发人员的Dapr——分布式世界的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。