asp网站数据库连接,制作网页的工具主要有哪些,重庆公司黄页企业名录,浙江建设信息港首页介绍面向.NET开发人员的Dapr——前言The world is distributed分布式世界Just ask any cool kid: Modern, distributed systems are in, and monolithic apps are out!随便问一个酷小子#xff0c;他们都会说#xff1a;现代、分布式系统时间已经到来#xff0c;单体应用已经成为… 面向.NET开发人员的Dapr——前言The world is distributed分布式世界Just ask any cool kid: Modern, distributed systems are in, and monolithic apps are out!随便问一个酷小子他们都会说现代、分布式系统时间已经到来单体应用已经成为过去式But, its 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. Theyre 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, lets 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. Theyre straightforward to:BuildTestDeployTroubleshootScale 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 arent 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 youve been in the technology business for any length of time, good chance youve experienced it. Its 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 cant 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. Its 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的新世界。目录面向.NET开发人员的Dapr——前言面向.NET开发人员的Dapr——分布式世界面向.NET开发人员的Dapr——俯瞰Dapr面向.NET开发人员的Dapr——入门面向.NET开发人员的Dapr——参考应用程序面向.NET开发人员的Dapr——状态管理面向.NET开发人员的Dapr——发布和订阅
