为何使用微服务方法构建应用程序？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 out or in, 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
单一式应用程序包含域特定的功能，通常按照功能层划分，例如 Web、业务和数据。A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.
单一式应用程序可通过复制到多个服务器/虚拟机/容器上进行扩展。You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.
微服务应用程序将单独功能分隔成单独的较小服务。A microservice application separates functionality into separate smaller services.
微服务方法可通过独立部署每个服务而扩大，跨服务器/虚拟机/容器创建这些服务的实例。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
*左侧的单一式方法具有单一数据库和多层的特定技术。*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.
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, 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 Services。Productive 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:
- 从传统单一式应用程序入手。Start with a traditional monolithic application.
- 迁移。Migrate. 使用容器或来宾可执行文件在 Service Fabric 中托管现有代码。Use containers or guest executables to host existing code in Service Fabric.
- 现代化。Modernize. 将新微服务与现有容器化代码一起添加。Add new microservices alongside existing containerized code.
- 创新。Innovate. 根据需求将单一式应用程序分解成微服务。Break the monolithic application into microservices based on need.
- 将应用程序转换为微服务。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.