您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

为何使用微服务方法构建应用程序?Why use a microservices approach to building applications?

对于软件开发人员,分解成组件部分的应用程序是什么新鲜事物。For software developers, factoring an application into component parts is nothing new. 通常情况下,一种分层的方法使用,与后端存储、 中间层业务逻辑和前端用户界面 (UI)。Typically, a tiered approach is used, with a back-end store, middle-tier business logic, and a front-end user interface (UI). 什么具有过去几年更改为开发人员构建分布式的云应用程序。What has changed over the last few years is that developers are building distributed applications for the cloud.

下面是一些不断变化的业务需求:Here are some changing business needs:

  • 生成并运营规模达到新的地理区域中的客户服务。A service that's built and operated at scale to reach customers in new geographic regions.
  • 特性和功能,以采用敏捷方式响应客户需求的速度更快交付。Faster delivery of features and capabilities to respond to customer demands in an agile way.
  • 提高资源利用率以降低成本。Improved resource utilization to reduce costs.

这些业务要求影响我们如何构建应用程序。These business needs are affecting how we build applications.

有关信息的 Azure 微服务方法的详细信息,请参阅微服务:由云支持的应用程序变革For more information about the Azure approach to microservices, see Microservices: An application revolution powered by the cloud.

整体化与微服务设计方法Monolithic vs. microservices design approach

应用程序会随着时间而发展。Applications evolve over time. 成功的应用程序因为有实用性而发展。Successful applications evolve by being useful to people. 失败的应用程序不不断向前发展,最终不推荐使用。Unsuccessful applications don't evolve and are eventually deprecated. 下面是这个问题: 多少了解您的要求目前和将来他们就是?Here's the question: how much do you know about your requirements today and what they'll be in the future? 例如,假设您要在你的公司构建部的报告应用程序。For example, let's say you're building a reporting application for a department in your company. 您确定应用程序将仅在你的公司范围内,并且,报表不会保存在长。You're sure the application applies only within the scope of your company and that the reports won't be kept long. 所用的方法是不同的说,为构建服务向数千万个客户提供视频内容。Your approach will be different from that of, say, building a service that delivers video content to tens of millions of customers.

有时,获取外寻求概念证明才是驱动因素。Sometimes, getting something out the door as a proof of concept is the driving factor. 您知道可以更高版本重新设计应用程序。You know the application can be redesigned later. 不存在过度设计内容根本就没有使用的小点。There's little point in over-engineering something that never gets used. 另一方面,公司针对云进行构建,假定条件下时,成长和使用量。On the other hand, when companies build for the cloud, the expectation is growth and usage. 成长和规模不可预知。Growth and scale are unpredictable. 我们希望原型快速同时也知道,我们可以处理将来的成功路径上。We want to prototype quickly while also knowing that we're on a path that can handle future success. 这是简练的启动方法:构建、测量、学习和迭代。This is the lean startup approach: build, measure, learn, and iterate.

在客户端/服务器时代,我们倾向专注于构建分层式应用程序在每个层中使用特定技术。During the client/server era, we tended to focus on building tiered applications by using specific technologies in each tier. 术语整体式已经出现了应用程序来描述这些方法。The term monolithic application has emerged to describe these approaches. 接口通常存在于各层之间,而在一层内的各组件之间采用更紧密耦合的设计。The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. 开发人员设计并分解已编译为库并链接到几个可执行文件和 Dll 在一起的类。Developers designed and factored classes that were compiled into libraries and linked together into a few executable files and DLLs.

没有为单一式设计方法带来的好处。There are benefits to a monolithic design approach. 单一式应用程序通常是设计较简单和组件间的调用是速度更快,因为这些调用通常是通过进程间通信 (IPC)。Monolithic applications are often simpler to design, and calls between components are faster because these calls are often over interprocess communication (IPC). 此外,每个人都只测试单一产品,这往往是人力资源更有效地使用。Also, everyone tests a single product, which tends to be a more efficient use of human resources. 缺点是分层之间紧密耦合,无法缩放各个组件。The downside is that there's a tight coupling between tiered layers, and you can't scale individual components. 如果需要执行修复或升级,你必须等待其他人完成其测试。If you need to do fixes or upgrades, you have to wait for others to finish their testing. 它很难变得敏捷。It's harder to be agile.

微服务解决了这些缺点,并更密切配合上述业务要求。Microservices address these downsides and more closely align with the preceding business requirements. 但它们也有优点和缺点。But they also have both benefits and liabilities. 微服务的优点是通常各自封装较为简单的业务功能,可独立缩放、测试、部署和管理。The benefits of microservices are that each one typically encapsulates simpler business functionality, which you can scale up or down, test, deploy, and manage independently. 微服务方法的一个重要优势是,团队根据业务方案的详细技术。One important benefit of a microservices approach is that teams are driven more by business scenarios than by technology. 较小的团队开发基于客户的应用场景的微服务,并使用他们想要使用任何技术。Smaller teams develop a microservice based on a customer scenario and use any technologies that they want to use.

换句话说,组织不需要为了维护微服务应用程序而将技术标准化。In other words, the organization doesn’t need to standardize tech to maintain microservice applications. 拥有服务的单个团队可以根据团队的专业知识,或什么最适合解决问题,各自发挥所长。Individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate to solve the problem. 在实践中,一组建议的技术,如特定的 NoSQL 存储或 web 应用程序框架,更可取。In practice, a set of recommended technologies, like a particular NoSQL store or web application framework, is preferable.

微服务的缺点是,您需要管理更多独立的实体并处理更复杂的部署和版本控制。The downside of microservices is that you have to manage more separate entities and deal with more complex deployments and versioning. 微服务之间的网络流量增加,因为执行相应的网络延迟。Network traffic between the microservices increases, as do the corresponding network latencies. 大量琐碎的精细服务可能会导致性能噩梦。Lots of chatty, granular services can cause a performance nightmare. 如果没有工具帮助您查看这些依赖项,很难看到整个系统。Without tools to help you view these dependencies, it's hard to see the whole system.

标准使微服务方法,通过指定如何进行通信并接受仅关注需要从一种服务,工作,而不是严格协定。Standards make the microservices approach work by specifying how to communicate and tolerating only the things you need from a service, rather than rigid contracts. 请务必在设计中定义预先这些协定,因为服务均可独立更新。It's important to define these contracts up front in the design because services update independently of each other. 在设计微服务方法时出现的另一个描述是“面向服务的精细体系结构 (SOA)”。Another description coined for designing with a microservices approach is “fine-grained service-oriented architecture (SOA).”

简单地说,微服务设计方法是分离的服务,具有各自独立更改和一致的标准通信的联合。At its simplest, the microservices design approach is about a decoupled federation of services, with independent changes to each and agreed-upon standards for communication.

随着更多云应用程序会生成,人们发现此分解成独立、 方案焦点式服务的整体应用程序是一种更好的长期方法。As more cloud applications are produced, people have discovered that this decomposition of the overall application into independent, scenario-focused services is a better long-term approach.

应用程序开发方法的比较Comparison between application development approaches

Service Fabric 平台应用程序开发

  1. 整体式应用程序包含特定于域的功能,并通常划分为像 web、 业务和数据的功能层。A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.

  2. 通过克隆多个服务器/虚拟机上缩放整体式应用程序/容器。You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.

  3. 微服务应用程序将单个功能分隔成单个较小的服务。A microservice application separates functionality into separate smaller services.

  4. 微服务方法可通过独立部署每个服务而扩展,跨服务器/虚拟机/容器创建这些服务的实例。The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

使用微服务设计方法不是适用于所有项目,但它确实更符合前面所述的业务目标。Designing with a microservices approach isn't appropriate for all projects, but it does align more closely with the business objectives described earlier. 如果您知道将有机会以微服务设计的更高版本重新编写代码,从单一式方法可能会有用。Starting with a monolithic approach might make sense if you know you'll have the opportunity to rework the code later into a microservices design. 更常见的是,从单一式应用程序入手,分阶段慢慢分解它(从需要提高可缩放性或敏捷性的功能区域开始)。More commonly, you begin with a monolithic application and slowly break it up in stages, starting with the functional areas that need to be more scalable or agile.

当使用微服务方法时,编写许多小型服务应用程序。When you use a microservices approach, you compose your application of many small services. 在跨计算机群集的部署的容器中运行这些服务。These services run in containers that are deployed across a cluster of machines. 较小的团队开发针对方案的服务和独立进行测试、 版本、 部署和扩展每个服务,因此可以改进整个应用程序。Smaller teams develop a service that focuses on a scenario and independently test, version, deploy, and scale each service so the entire application can evolve.

什么是微服务?What is a microservice?

微服务存在多种定义。There are different definitions of microservices. 但广泛接受的大部分微服务的以下特征:But most of these characteristics of microservices are widely accepted:

  • 封装客户方案或业务方案。Encapsulate a customer or business scenario. 要解决什么问题?What problem are you solving?
  • 由小型工程团队开发。Developed by a small engineering team.
  • 在任何编程语言中,使用任何框架编写。Written in any programming language, using any framework.
  • 包含代码,并可以选择状态,这两个独立控制版本、 部署和缩放。Consist of code, and optionally state, both of which are independently versioned, deployed, and scaled.
  • 通过定义完善的接口和协议来与其他微服务交互。Interact with other microservices over well-defined interfaces and protocols.
  • 具有唯一名称 (Url),用于解析其位置。Have unique names (URLs) that are used to resolve their location.
  • 在出现故障时可保持一致且可用。Remain consistent and available in the presence of failures.

总而言之,:To sum that up:

微服务应用程序由独立控制版本和可缩放的、以客户为中心的服务组成,这些服务通过标准协议和定义完善的接口彼此通信。Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces.

在任何编程语言中,使用任何框架编写Written in any programming language, using any framework

作为开发人员,我们想要随意选择的语言或框架,具体取决于我们的技能和我们要创建的服务的需求。As developers, we want to be free to choose a language or framework, depending on our skills and the needs of the service that we're creating. 对于某些服务,可能值的性能优势C++上面任何其他操作。For some services, you might value the performance benefits of C++ above anything else. 对于其他操作系统,从获取的托管开发的易用性C#或 Java 可能是更重要的。For others, the ease of managed development that you get from C# or Java might be more important. 在某些情况下,可能需要用于特定合作伙伴库、 数据存储技术或方法将向客户端服务公开。In some cases, you might need to use a specific partner library, data storage technology, or method for exposing the service to clients.

选择一种技术后,您需要考虑操作或生命周期管理和缩放的服务。After you choose a technology, you need to consider the operational or life-cycle management and scaling of the service.

允许独立控制版本、部署及缩放的代码和状态Allows code and state to be independently versioned, deployed, and scaled

无论您编写的方式在微服务、 代码,以及 (可选) 状态,应单独部署、 升级和缩放。No matter how you write your microservices, the code, and optionally the state, should independently deploy, upgrade, and scale. 此问题很难解决由于这取决于所选的技术。This problem is hard to solve because it comes down to your choice of technologies. 缩放,了解如何分区 (或分片) 代码和状态是一个挑战。For scaling, understanding how to partition (or shard) both the code and the state is challenging. 当代码和状态使用不同的技术,目前不常见,微服务的部署脚本需要能够扩展这两个。When the code and state use different technologies, which is common today, the deployment scripts for your microservice need to be able to scale them both. 这种分离也是有关敏捷性和灵活性,因此可以无需同时升级所有这些升级某些微服务。This separation is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

让我们返回到我们的一段时间的整体化和微服务方法的比较。Let's return to our comparison of the monolithic and microservices approaches for a moment. 此图显示了存储状态的方法中的差异:This diagram shows the differences in the approaches to storing state:

两种方法的状态存储State storage for the two approaches

Service Fabric 平台状态存储

单一式方法,在左侧,有一个单一数据库和层的特定技术。The monolithic approach, on the left, has a single database and tiers of specific technologies.

微服务方法中,在右侧,有互连的微服务的状态通常应用范围限定为微服务和使用各种技术关系图。The microservices approach, on the right, has a graph of interconnected microservices where state is typically scoped to the microservice and various technologies are used.

在单一式方法中,应用程序通常使用单一数据库。In a monolithic approach, the application typically uses a single database. 使用一个数据库的优点是,它是在一个位置,这样更易于部署。The advantage to using one database is that it's in a single location, which makes it easy to deploy. 每个组件可以通过单个表来存储其状态。Each component can have a single table to store its state. 困难之处在于团队必须严格区分状态。Teams need to strictly separate state, which is a challenge. 不可避免地,我们不久就会想要向现有客户表中添加列、 表之间执行联接和存储层形成依赖性。Inevitably, someone will be tempted to add a column to an existing customer table, do a join between tables, and create dependencies at the storage layer. 发生这种情况后,无法缩放各个组件。After this happens, you can't scale individual components.

在微服务方法中,每个服务都管理并存储自己的状态。In the microservices approach, each service manages and stores its own state. 每个服务将负责同时缩放代码和状态,以满足服务的需求。Each service is responsible for scaling both code and state together to meet the demands of the service. 不足的是,当您需要创建视图或查询的应用程序的数据,你需要跨多个状态存储进行查询。A downside is that when you need to create views, or queries, of your application’s data, you need to query across multiple state stores. 通常通过单独的微服务的一系列微服务生成的视图,解决此问题。This problem is typically solved by a separate microservice that builds a view across a collection of microservices. 如果需要对数据运行多个即席查询,则应考虑每个微服务的数据写入数据仓库服务以供脱机分析。If you need to run multiple impromptu queries on the data, you should consider writing each microservice’s data to a data warehousing service for offline analytics.

微服务进行版本控制。Microservices are versioned. 就可以针对不同版本的并行运行的微服务。It's possible for different versions of a microservice to run side by side. 微服务的较新版本无法在升级过程失败,并且需要将其回滚到早期版本。A newer version of a microservice could fail during an upgrade and need to be rolled back to an earlier version. 版本控制技术还有助于对于 A / B 测试,其中不同的用户体验不同版本的服务。Versioning is also helpful for A/B testing, where different users experience different versions of the service. 例如,它是常见升级微服务的一组特定的客户可以将它广泛应用的详细信息之前,测试新功能。For example, it's common to upgrade a microservice for a specific set of customers to test new functionality before rolling it out more widely.

通过定义完善的接口和协议来与其他微服务交互Interacts with other microservices over well-defined interfaces and protocols

在过去 10 年中,大量信息已发布描述面向服务的体系结构中的通信模式。Over the past 10 years, extensive information has been published describing communication patterns in service-oriented architectures. 一般而言,服务通信使用 REST 方法,并配合 HTTP 与 TCP 协议及 XML 或 JSON 作为序列化格式。Generally, service communication uses a REST approach with HTTP and TCP protocols and XML or JSON as the serialization format. 从接口的角度看,这就是采用 web 设计方法。From an interface perspective, it's about taking a web design approach. 但不是应阻止您使用二进制协议或您自己的数据格式。But nothing should stop you from using binary protocols or your own data formats. 只需注意,用户将有较难使用微服务,如果这些协议和格式并不公开可用。Just be aware that people will have a harder time using your microservices if these protocols and formats aren't openly available.

具有用来解析位置的唯一名称 (URL)Has a unique name (URL) used to resolve its location

微服务需是可寻址的只要它正在运行。Your microservice needs to be addressable wherever it's running. 如果您认为有关机的信息,哪一个正在运行特定微服务,可能会错误快速。If you're thinking about machines and which one is running a particular microservice, things can go bad quickly.

就像 DNS 解析特定计算机的特定 URL 一样,微服务需要有唯一的名称来发现它目前所在的位置。In the same way that DNS resolves a particular URL to a particular machine, your microservice needs a unique name so that its current location is discoverable. 微服务需要可寻址的名称,独立于其运行的基础结构。Microservices need addressable names that are independent of the infrastructure they're running on. 这意味着由于存在需要服务注册表没有如何部署你的服务和发现方式之间的交互。This implies that there's an interaction between how your service is deployed and how it's discovered, because there needs to be a service registry. 当一台计算机失败时,需要告诉您,该服务已移至注册表服务。When a machine fails, the registry service needs to tell you where the service was moved to.

在出现故障时可保持一致且可用Remains consistent and available in the presence of failures

处理意外的故障是最难解决的问题之一,特别是在分布式系统中。Dealing with unexpected failures is one of the hardest problems to solve, especially in a distributed system. 我们作为开发人员编写大部分是代码的用于处理异常。Much of the code that we write as developers is for handling exceptions. 在测试期间,我们也会花费时间最多异常处理。During testing, we also spend the most time on exception handling. 该过程是比编写代码来处理故障更为复杂。The process is more involved than writing code to handle failures. 在其运行的微服务在计算机出现故障时,会发生什么情况?What happens when the machine on which the microservice is running fails? 您需要检测故障,这是本身是一个难题。You need to detect the failure, which is a hard problem on its own. 但您还需要重新启动微服务。But you also need to restart your microservice.

可用性、 微服务需要可灵活处理故障并能够在另一台计算机上重新启动。For availability, a microservice needs to be resilient to failures and able to restart on another machine. 除了这些可恢复性要求,数据不应将丢失,并且数据需要保持一致。In addition to these resiliency requirements, data shouldn't be lost, and data needs to remain consistent.

如果在应用程序升级期间发生故障,则很难实现复原。Resiliency is hard to achieve when failures happen during an application upgrade. 在配合部署系统一起运行时,微服务不仅需要恢复。The microservice, working with the deployment system, doesn't need to recover. 它需要确定是否要继续向前移动到较新版本或回滚到旧版以维持一致的状态。It needs to determine whether it can continue to move forward to the newer version or roll back to a previous version to maintain a consistent state. 您需要考虑几个问题,如足够多的计算机是否可用于继续更新以及如何恢复以前版本的微服务。You need to consider a few questions, like whether enough machines are available to keep moving forward and how to recover previous versions of the microservice. 要做出这些决策,您需要在微服务发出运行状况信息。To make these decisions, you need the microservice to emit health information.

报告运行状况和诊断Reports health and diagnostics

这看起来可能很明显,并经常被忽略,但微服务需要报告其运行状况和诊断。It might seem obvious, and it's often overlooked, but a microservice needs to report its health and diagnostics. 否则,您必须很少深入了解其运行状况: 从操作角度来说。Otherwise, you have little insight into its health from an operations perspective. 面临的难题是关联一组独立服务的诊断事件并修正计算机时钟偏差以识别事件顺序。Correlating diagnostic events across a set of independent services, and dealing with machine clock skews to make sense of the event order, is challenging. 同样地,通过议定的协议和数据格式来与微服务交互时,需要将运行状况和诊断事件的记录方式标准化,这些事件最终将写入可供查询和查看的事件存储。In the same way that you interact with a microservice over agreed-upon protocols and data formats, you need to standardize how to log health and diagnostic events that will ultimately end up in an event store for querying and viewing. 微服务方法,不同的团队需要达成单个日志记录格式。With a microservices approach, different teams need to agree on a single logging format. 需要有一致的方法来查看整个应用程序中的诊断事件。There needs to be a consistent approach to viewing diagnostic events in the application as a whole.

运行状况与诊断不同。Health is different from diagnostics. 运行状况是指微服务报告其当前状态,以便采取适当的措施。Health is about the microservice reporting its current state to take appropriate actions. 一个很好的例子便是使用升级和部署机制来保持可用性。A good example is working with upgrade and deployment mechanisms to maintain availability. 尽管一个服务可能由于进程崩溃是当前不正常或计算机重启,可能仍可运行该服务。Though a service might be currently unhealthy because of a process crash or machine reboot, the service might still be operational. 所需的最后一步是通过启动升级使情况变得更糟。The last thing you need is to make the situation worse by starting an upgrade. 最佳方法是先调查或留出时间进行恢复的微服务。The best approach is to investigate first or allow time for the microservice to recover. 微服务中的运行状况事件可以帮助我们制定明智的决策,并且实际上也有助于创建自愈服务。Health events from a microservice help us make informed decisions and, in effect, help create self-healing services.

Azure 上设计微服务的指南Guidance for designing microservices on Azure

在访问 Azure 体系结构中心指南设计和构建微服务在 Azure 上Visit the Azure architecture center for guidance on designing and building microservices on Azure.

Service Fabric 作为微服务平台Service Fabric as a microservices platform

Microsoft 从提供的服务提供盒装的产品,通常是单一式,转换时,azure Service Fabric 横空问世。Azure Service Fabric emerged when Microsoft transitioned from delivering boxed products, which were typically monolithic, to delivering services. 构建和运营大型服务,如 Azure SQL 数据库和 Azure Cosmos DB 的经验造就了 Service Fabric。The experience of building and operating large services, like Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. 在平台随着时间不断演变更多服务采用它。The platform evolved over time as more services adopted it. Service Fabric 不仅要在 Azure 中运行,还要在独立的 Windows Server 部署中运行。Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

Service Fabric 的目的是为了解决构建和运行服务方面的难题,并有效地使用基础结构资源,因此团队通过使用微服务方法来解决业务问题。The aim of Service Fabric is to solve the hard problems of building and running a service and to use infrastructure resources efficiently, so teams can solve business problems by using a microservices approach.

Service Fabric 可帮助你构建使用微服务方法的应用程序,它提供:Service Fabric helps you build applications that use a microservices approach by providing:

  • 提供系统服务的平台,用于部署、升级、检测和重启失败的服务、发现服务、路由消息、管理状态和监视运行状况。A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover services, route messages, manage state, and monitor health.
  • 能够部署在容器中或作为进程运行的应用程序。The ability to deploy applications either running in containers or as processes. Service Fabric 是容器和进程 Orchestrator。Service Fabric is a container and process orchestrator.
  • 若要帮助您构建微服务的应用程序的生产编程 Api:ASP.NET Core、Reliable Actors 和 Reliable ServicesProductive programming APIs to help you build applications as microservices: ASP.NET Core, Reliable Actors, and Reliable Services. 例如,可以获取运行状况和诊断信息,或利用内置的高可用性。For example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

Service Fabric 并不知道有关如何构建你的服务,并且可以使用任何技术。但它提供内置编程 Api,使其更轻松地生成微服务。Service Fabric is agnostic about how you build your service, and you can use any technology. But it does provide built-in programming APIs that make it easier to build microservices.

将现有应用程序迁移到 Service FabricMigrating existing applications to Service Fabric

Service Fabric 允许您重用现有代码,让其现代化与新的微服务。Service Fabric allows you to reuse existing code and modernize it with new microservices. 有五个阶段应用程序现代化,并可以启动和停止在任何阶段。There are five stages to application modernization, and you can start and stop at any stage. 阶段包括:The stages are:

  1. 从传统单一式应用程序入手。Start with a traditional monolithic application.
  2. 迁移。Migrate. 使用容器或来宾可执行文件托管在 Service Fabric 中的现有代码。Use containers or guest executables to host existing code in Service Fabric.
  3. 实现现代化。Modernize. 添加新的微服务与现有容器化代码一起。Add new microservices alongside existing containerized code.
  4. 创新。Innovate. 单一式应用程序分解为微服务根据需求。Break the monolithic application into microservices based on need.
  5. 转换为微服务的应用程序。Transform applications into microservices. 转换现有单一式应用程序或生成新领域应用程序。Transform existing monolithic applications or build new greenfield applications.


请记住,你可以在任意阶段开始和停止Remember, you can start and stop at any of these stages. 你没有前进到下一阶段。You don't have to progress to the next stage.

让我们看看示例每个阶段。Let's look at examples for each of these stages.

两个原因,许多公司要迁移到容器的现有单一式应用程序:For two reasons, many companies are migrating existing monolithic applications into containers:

  • 成本的降低,由于整合和移除现有硬件或由于在更高的密度运行的应用程序。Cost reduction, either due to consolidation and removal of existing hardware or due to running applications at higher density.
  • 开发和运营之间一致的部署协定。A consistent deployment contract between development and operations.

多来成本的降低非常简单。Cost reductions are straightforward. 在 Microsoft,许多现有应用程序正在进行容器化,从而导致数以百万计的美元的成本节约。At Microsoft, many existing applications are being containerized, leading to millions of dollars in savings. 一致的部署是难以评估,但同样重要。Consistent deployment is harder to evaluate but equally important. 这意味着开发人员可以选择根据它们的技术,但操作将接受方法只有一个用于部署和管理应用程序。It means that developers can choose the technologies that suit them, but operations will accept only a single method for deploying and managing the applications. 它减少了从无需处理而不会迫使开发人员可以选择仅特定技术支持不同的技术的复杂操作。It alleviates operations from having to deal with the complexity of supporting different technologies without forcing developers to choose only certain ones. 从根本上来说,每个应用程序都容器化到独立式的部署映像。Essentially, every application is containerized into self-contained deployment images.

许多组织止步于这一阶段。Many organizations stop here. 他们已有的容器,好处和 Service Fabric 提供了完整的管理体验,包括部署、 升级、 版本控制、 回滚、 和运行状况监视。They already have the benefits of containers, and Service Fabric provides the complete management experience, including deployment, upgrades, versioning, rollbacks, and health monitoring.

现代化是的新服务与现有容器化代码一起添加。Modernization is the addition of new services alongside existing containerized code. 如果您要编写新代码,最好下微服务路径的几步。If you're going to write new code, it's best to take small steps down the microservices path. 这可能意味着添加新的 REST API 终结点或新的业务逻辑。This could mean adding a new REST API endpoint or new business logic. 这样一来,您开始构建新的微服务并进行开发和部署它们的过程。In this way, you start the process of building new microservices and practice developing and deploying them.

微服务方法可适应不断变化的业务需求。A microservices approach accommodates changing business needs. 在此阶段,您需要决定是否开始拆分将整体式应用程序服务,或进行创新。At this stage, you need to decide whether to start splitting the monolithic application into services, or innovating. 当使用作为工作流队列的数据库将成为处理瓶颈时,典型的示例。A classic example here is when a database that you're using as a workflow queue becomes a processing bottleneck. 随着工作流请求数量不断增加,需要分布工作,以实现缩放。As the number of workflow requests increases, the work needs to be distributed for scale. 需要的应用程序,不能扩展,或需要更频繁地更新并将其扩展拆分为微服务和创新该特定的部分。Take that particular piece of the application that's not scaling, or that needs to be updated more frequently, and split it out as a microservice and innovate.

转换为微服务的应用程序Transform applications into microservices
在此阶段,你的应用程序是完全的组合 (或拆分成) 微服务。At this stage, your application is fully composed of (or split into) microservices. 若要达到此限制,您已微服务之旅。To reach this point, you've made the microservices journey. 您可以从此阶段开始,但为此,而无需使用微服务平台,帮助你需要投入大量资金。You can start here, but to do so without a microservices platform to help you requires a significant investment.

微服务适合我的应用程序吗?Are microservices right for my application?

也许。Maybe. 在 Microsoft,随着更多团队开始构建云应用出于业务原因,其中许多意识到采用类似微服务的方法的优势。At Microsoft, as more teams began to build for the cloud for business reasons, many of them realized the benefits of taking a microservice-like approach. 必应,例如,一直在使用微服务多年。Bing, for example, has been using microservices for years. 微服务方法对于其他团队而言相当新颖。For other teams, the microservices approach was new. 团队发现需要解决一些疑难问题,但这并非他们的强项。Teams found that there were hard problems to solve outside of their core areas of strength. 这是 Service Fabric 受到重视的技术构建的服务的原因。This is why Service Fabric gained traction as the technology for building services.

Service Fabric 的目的是减少构建微服务应用程序,因此不需要经历多成本高昂的重新设计的复杂性。The objective of Service Fabric is to reduce the complexities of building microservice applications so that you don't have to go through as many costly redesigns. 从小规模开始,按需缩放,淘汰旧服务,添加新服务,并随着客户用量的增加而改进。Start small, scale when needed, deprecate services, add new ones, and evolve with customer usage. 我们也知道,为了让微服务更易于为大部分开发人员所接受,还有许多其他尚待解决的问题。We also know that there are many other problems yet to be solved to make microservices more approachable for most developers. 容器和执行组件编程模型是在该方向的小步骤的示例。Containers and the actor programming model are examples of small steps in that direction. 我们确定更多的创新应运而生,微服务方法更轻松。We're sure more innovations will emerge to make a microservices approach easier.

后续步骤Next steps