为什么通过微服务的方法生成应用程序?Why a microservices approach to building applications?

作为软件开发人员,我们已知道思考如何将应用程序因数分解成组件部分。As software developers, there is nothing new in how we think about factoring an application into component parts. 后端存储、中间层业务逻辑和前端用户界面 (UI) 通常采用一种分层方法。Typically, a tiered approach is taken 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 we, as developers, are building distributed applications for the cloud.

不断变化的业务需求包括:The changing business needs are:

  • 为吸引新地理区域的客户而大规模构建和操作的一项服务。A service that's built and operates at scale to reach customers in new geographical regions.
  • 更快速地提供特性与功能,灵活应对客户的需求。Faster delivery of features and capabilities to be able 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 approach of Azure to microservices, read Microservices: An application revolution powered by the cloud.

单一式设计方法与微服务设计方法Monolithic vs. microservice design approach

应用程序会随着时间而发展。Applications evolve over time. 成功的应用程序因为有实用性而发展。Successful applications evolve by being useful to people. 失败的应用程序不会发展,最终将被取代。Unsuccessful applications do not evolve and eventually are deprecated. 问题是:现在对要求了解多少,未来又有何变化?The question is: How much do you know about your requirements today, and what will they be in the future? 例如,如果要为某个部门构建报表应用程序。For example, let's say that you are building a reporting application for a department. 可以确定的是,应用程序仅在公司范围内适用,而且报表的生存期非常短。You are sure that the application only applies within the scope of your company and that the reports are short-lived. 那么,选择的方法将不同于构建服务向数千万个客户传送视频内容的方式。Your choice of approach is different from, say, building a service that delivers video content to tens of millions of customers.

在已知后来可以重新设计应用程序的情况下,有时向外寻求概念证明才是驱动因素。Sometimes, getting something out the door as proof of concept is the driving factor, while you know that the application can be redesigned later. 过度设计永不使用的功能并没有太大意义。There is little point in over-engineering something that never gets used. 这就是通常所谓的工程取舍。It's the usual engineering trade-off. 另一方面,公司谈论生成云时都期望成长和使用量。On the other hand, when companies talk about building for the cloud, the expectation is growth and usage. 问题在于成长和规模不可预测。The issue is that growth and scale are unpredictable. 我们想要能够快速创建原型,同时还要了解我们正在通往未来成功的路上。We would like to be able to prototype quickly while also knowing that we are on a path to deal with 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 for 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 executables and DLLs.

这类单一式设计方法有一些优点。There are benefits to such a monolithic design approach. 设计较简单,组件之间通常通过进程间通信 (IPC) 调用,因此调用更快。It's often simpler to design, and it has faster calls between components because these calls are often over interprocess communication (IPC). 此外,每个人都只测试单一产品,人力资源运用更有效率。Also, everyone tests a single product, which tends to be more people-resource efficient. 缺点是分层之间紧密耦合,无法缩放单独组件。The downside is that there's a tight coupling between tiered layers, and you cannot scale individual components. 如果需要执行修复或升级,必须等待其他人完成其测试。If you need to perform fixes or upgrades, you have to wait for others to finish their testing. 灵活性更难以发挥。It is more difficult 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 microservice approach is that teams are driven more by business scenarios than by technology--which the tiered approach encourages. 实际上,较小的团队可以根据客户方案开发微服务,采用他们选择的任何技术。In practice, smaller teams develop a microservice based on a customer scenario and use any technologies they choose.

换句话说,组织不需要为了维护微服务应用程序而将技术标准化。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, such as a particular NoSQL store or web application framework, is preferable.

微服务的缺点包括需要管理越来越多的独立实体、处理更复杂的部署和版本控制。The downside of microservices comes in managing the increased number of separate entities and dealing with more complex deployments and versioning. 微服务之间的网络流量以及相应的网络延迟不断增加。Network traffic between the microservices increases as well as the corresponding network latencies. 可以通过大量琐碎但却精细的服务来解决性能问题。Lots of chatty, granular services are a recipe for a performance nightmare. 如果没有工具帮助查看这些依赖性,很难“看到”整个系统。Without tools to help view these dependencies, it is hard to "see" the whole system.

若要让微服务方法奏效,必须在以下方面制定标准:在通信方式上达成共识,只注重需要从服务获得什么,不在乎僵化的约定。Standards make the microservice approach work by agreeing on how to communicate and being tolerant of only the things you need from a service, rather than rigid contracts. 必须在设计的初期定义这些约定,因为之后服务将各自独立更新。It is 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 apps are produced, people have discovered that this decomposition of the overall app into independent, scenario-focused services is a better long-term approach.

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

Service Fabric 平台应用程序开发

  1. 单一式应用包含域特定的功能,通常按照功能层来划分,例如 Web、业务和数据。A monolithic app contains domain-specific functionality and is normally divided by functional layers such as web, business, and data.

  2. 单一式应用可通过复制到多个服务器/虚拟机/容器上进行扩展。You scale a monolithic app 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 microservice approach is not a panacea for all projects, but it does align more closely with the business objectives described earlier. 如果确定以后有机会根据微服务设计重写代码,可以从单一式方法入手。Starting with a monolithic approach might be acceptable if you know that you will 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.

微服务方法是以许多小服务来组成应用程序。The microservice approach means that you compose your application of many small services. 这些服务在部署于计算机群集上的容器中运行。The 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 that the entire application can evolve.

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

微服务有不同的定义。There are different definitions of microservices. 但在微服务的以下大部分特性上,已广泛达成共识:However, most of the following characteristics of microservices are widely agreed upon:

  • 封装客户方案或业务方案。Encapsulate a customer or business scenario. 要解决什么问题?What is the problem you are solving?
  • 由小型工程团队开发。Developed by a small engineering team.
  • 使用任何编程语言编写并使用任何框架。Written in any programming language and use 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) used to resolve their location.
  • 在出现故障时可保持一致且可用。Remain consistent and available in the presence of failures.

综上所述:In summary:

微服务应用程序由独立控制版本和可缩放的、以客户为中心的服务组成,这些服务通过标准协议和定义完善的接口彼此通信。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 and use any framework

作为开发人员,我们应该根据本身的技能或服务需求,自由选择所需的语言或框架。As developers, we want to be free to choose a language or framework that we want, depending on our skills or the needs of the service. 在某些服务中,可能会认为 C++ 的性能优点胜于一切。In some services, you might value the performance benefits of C++ above all else. 而在其他服务中,C# 或 Java 的简易管理开发可能才是最重要的。In other services, the ease of managed development in C# or Java might be most important. 在某些情况下,可能需要使用特定合作伙伴库、数据存储技术,或向客户端公开服务的方式。In some cases, you may need to use a specific partner library, data storage technology, or means of exposing the service to clients.

选择技术之后,接下来的课题就是服务的操作或生命周期管理和缩放。After you have chosen a technology, you come to the operational or lifecycle management and scaling of the service.

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

无论选择何种方式来编写微服务,代码和(可选)状态都应该独立部署、升级和缩放。However you choose to write your microservices, the code, and optionally the state, should independently deploy, upgrade, and scale. 这是难以解决的问题之一,因为这涉及到所选的技术。This is one of the harder problems to solve because it comes down to your choice of technologies. 在缩放方面,难以了解如何分区(或分片)代码和状态。For scaling, understanding how to partition (or shard) both the code and state is challenging. 当代码和状态使用不同的技术时(目前的普遍情况),微服务的部署脚本必须能够妥善缩放两者。When the code and state use separate technologies, which is common today, the deployment scripts for your microservice need to be able to scale them both. 这也关乎到灵活性和弹性,以便可以升级某些微服务,而无需一次性全部升级。This is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

暂时回到单一式方法和微服务方法的比较,下图显示了状态存储方法的差异。Returning to the monolithic versus microservice approach for a moment, the following diagram shows the differences in the approach to storing state.

应用程序样式之间的状态存储State storage between application styles

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 is that it is 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 there are temptations to add a new 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 there is a need to create views, or queries, of your application's data, you need to query across multiple state stores. 为了解决此问题,通常由一个独立的微服务生成一个跨许多微服务的视图。Typically, this is solved by having a separate microservice that builds a view across a collection of microservices. 如果需要对数据执行多个即席查询,每个微服务应该考虑将其数据写入数据仓库服务以供脱机分析。If you need to perform multiple impromptu queries on the data, each microservice should consider writing its data to a data warehousing service for offline analytics.

微服务受版本控制,某个微服务的不同版本可能同时运行。Microservices are versioned and it is possible that different versions of a microservice may be running side-by-side. 较新版的微服务可能在升级期间失败,并需要回滚到旧版。A newer version of a microservice may fail during upgrade and need to be rolled back to an earlier version. 版本控制还有助于执行 A/B 式测试,其中不同的用户将体验到不同版本的服务。Versioning is also helpful for A/B-style testing, where different users experience different versions of the service. 例如,在更广泛推出新功能之前,通常先对一组特定的客户升级微服务以测试新功能。For example, it is 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 年来发布的大量关于面向服务的体系结构的文献对通信模式做了介绍。Extensive literature about service-oriented architecture has been published over the past 10 years describing communication patterns. 一般而言,服务通信使用 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 is about embracing the web design approach. 但是,用户仍然可以使用二进制协议或自己的数据格式。But nothing stops you from using binary protocols or your own data formats. 如果这些协议和格式非公开可用,微服务使用起来就很难,因此要有心理准备。Be prepared for people to have a harder time using your microservices if these protocols and formats are not openly available.

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

微服务无论在何处运行,都必须可寻址。Your microservice needs to be addressable wherever it is running. 若要在计算机上运行特定微服务,很快就会陷入困境。If you are thinking about machines and which one is running a particular microservice, things 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 are running on. 这意味着服务的部署和发现方式之间互相影响,因为需要有服务注册表。This implies that there is an interaction between how your service is deployed and how it is discovered, because there needs to be a service registry. 当计算机发生故障时,注册表服务必须指出服务已移到何处。When a machine fails, the registry service must 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 handling exceptions, and this is also where the most time is spent in testing. 问题比编写代码来处理故障更复杂。The problem is more involved than writing code to handle failures. 当运行微服务的计算机发生故障时,该怎么办?What happens when the machine where the microservice is running fails? 不仅需要检测这种故障(本身就是棘手的问题),还需要设法重启微服务。Not only do you need to detect the failure (a hard problem on its own), but you also need to restart your microservice.

出于可用性理由,微服务必须能够从故障复原,并能够在另一台计算机上重启。For availability reasons, a microservice needs to be resilient to failures and able to restart on another machine. 除了运行中代码的复原能力以外,不应该发生任何数据丢失,并且数据需要保持一致。In addition to the running code being resilient, there shouldn't be any data loss and the 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 decide whether it can continue to move forward to the newer version or instead roll back to a previous version in order to maintain a consistent state. 需要考虑一些问题,例如,是否有足够的计算机用于继续升级,以及如何恢复旧版的微服务。Questions such as whether enough machines are available to keep moving forward and how to recover previous versions of the microservice need to be considered. 需要微服务发出运行状况信息才能做出这些决定。This requires the microservice to emit health information to make these decisions.

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

微服务必须报告其运行状况和诊断,这一点看似明显,但却经常被忽视。It may seem obvious, and it is often overlooked, but a microservice must report its health and diagnostics. 否则,难以从操作角度深入了解其运行状况。Otherwise, there is 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. 在微服务方法中,关键在于不同团队同意采用单一记录格式。In a microservices approach, it's key that different teams 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. 当前服务可能由于进程崩溃或计算机重新启动而状况不正常,但仍可运行。Although a service may be currently unhealthy due to a process crash or machine reboot, the service might still be operational. 不应该执行升级而让情况恶化。The last thing you need is to make this worse by performing an upgrade. 最好是先进行调查,或让微服务有时间恢复。The best approach is to do an investigation 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.

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

Azure 从提供盒装产品(通常是单一式)转换到提供服务后,Azure Service Fabric 横空问世。Azure Service Fabric emerged when Azure transitioned from delivering boxed products, which were typically monolithic in style, to delivering services. 构建和运营 Azure SQL 数据库和 Azure Cosmos DB 等大型服务的经验造就了 Service Fabric。The experience of building and operating large services, such as Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. 该平台随着越来越多服务采用它而不断发展变化。The platform evolved over time as more and 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 utilize infrastructure resources efficiently, so that teams can solve business problems 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.
  • 能够部署在容器中运行或作为进程运行的应用程序。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 on how you build your service, and you can use any technology. However, 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, which can then be modernized with new microservices. 应用程序现代化分为五个阶段,可以在任意阶段开始和停止操作。There are five stages to application modernization, and you can start and stop at any of the stages. 其中包括:These are:

  1. 从传统单一式应用程序入手。Start with a traditional monolithic application.
  2. 直接迁移 - 使用容器或来宾可执行文件在 Service Fabric 中托管现有代码。Lift and Shift - Use containers or guest executables to host existing code in Service Fabric.
  3. 现代化 - 将新微服务与现有容器化代码一起添加。Modernization - New microservices added alongside existing containerized code.
  4. 创新 - 完全根据需求,将单一式应用程序分解成微服务。Innovate - Break the monolithic into microservices purely based on need.
  5. 转换为微服务 - 转换现有的单一式应用程序,或生成新领域应用程序。Transformed into microservices - the transformation of existing monolithic applications or building new greenfield applications.


有必要再次强调,可以在其中任一阶段启动和停止。It is important to emphasize again that you can start and stop at any of these stages. 不会强迫你继续前进到下一阶段。You are not compelled to progress to the next stage. 现在,让我们来看看每个阶段的示例。Let's now look at examples for each of these stages.

直接迁移Lift and Shift
许多公司都出于两个原因,将现有单一式应用程序直接迁移到容器中:Large numbers of companies are lifting and shifting existing monolithic applications into containers for two reasons:

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

成本降低可以理解,在 Azure 内部,大量现有应用程序正在进行容器化,节省的成本就高达数百万美元。Cost reductions are understandable, and within Azure, large numbers of existing applications are being containerized simply to save millions of dollars. 虽然部署一致性难以评估,但同样很重要。Consistent deployment is harder to evaluate, but equally as important. 这意味着,开发者仍可以自由选择适合自己的技术;不过,运营人员只接受使用一种方法来部署和管理这些应用程序。It means that developers can still be free to choose the technology that suits them, however the operations will only accept a single way to deploy and manage these applications. 这样可以减轻运营压力,不必处理许多不同的复杂技术,也不用强制开发者只选择特定技术。It alleviates the operations from having to deal with the complexity of many different technologies or forcing developers to only choose 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 from deployment, upgrades, versioning, rollbacks, health monitoring etc.

将新服务与现有容器化代码一起添加。The addition of new services alongside existing containerized code. 若要编写新代码,最好决定在微服务之旅上略进几步。If you are going to write new code, it is best to decide to take small steps down the microservices path. 可以是添加新的 REST API 终结点,也可以是添加新的业务逻辑。This could be adding a new REST API endpoint, or new business logic. 这样,便可以开始生成新的微服务,并进行开发和部署。This way, you start on the journey of building new microservices and practice developing and deploying them.

微服务方法可适应不断变化的业务需求。A microservices approach accommodates changing business needs. 在此阶段,决策是要将单一式应用拆分为服务,还是进行创新。At this stage the decision is whether you need to start splitting the monolithic app into services, or innovating. 例如,被用作工作流队列时,数据库在处理方面成为瓶颈。An example here is when a database being used as a workflow queue becomes a processing bottleneck. 随着工作流请求数量不断增加,需要分布工作,以实现缩放。As the number of workflow requests increases, the work needs to be distributed for scale. 对于不缩放或需要频繁更新的特定应用程序部分,将其分解为微服务,并进行创新。For that particular piece of the application that is not scaling, or that needs to be updated more frequently, split this out into a microservice and innovate.

转换为微服务Transformed into microservices
在此阶段,应用程序完全由微服务组成或分解为微服务。This is where your application is fully composed of (or decomposed into) microservices. 到此,已完成微服务之旅。To reach here, you have made the microservices journey. 虽然可以从此阶段开始,但如果没有微服务平台提供帮助,这会是一项巨额投资。You can start here, but to do this without a microservices platform to help you is a significant investment.

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

也许。Maybe. 根据我们的经验,随着 Azure 中越来越多团队开始出于商业理由而以云为目标来生成,有许多团队都了解到采用类似微服务的方法所带来的优点。What we experienced was that as more and more teams in Azure 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 developing 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 of choice for building services.

Service Fabric 的目标是将构建微服务应用程序的复杂性降低,使你不需要经历许多耗费成本的重新设计工作。The objective of Service Fabric is to reduce the complexities of building microservice applications so that you do not 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, and we are sure that more innovations will emerge to make this easier.

后续步骤Next steps