I am a big fan of microservices. And at the same time, I am not always so fond of them. Sometimes working with microservices reminds me of quotes like “small is big” and “slow and steady wins the race.” At the same time, sometimes it reminds me of the quote “too many cooks spoil the broth “ too.

我是微服务的忠实拥护者。 同时，我并不总是那么喜欢他们。 有时，与微服务一起工作使我想起诸如“小是大”和“缓慢而稳定的胜利 ”之类的名言。 同时，有时它也使我想起“太多的厨师损坏了汤 ”的说法。

Back in 2014, I was working as a Software Engineering Lead for a company that was going through a digital transformation by adopting a microservices architecture. The words digital, transformation, and microservice were all music to my ears. At that time, as an Engineering Lead (I’m currently a Solutions Architect) I was curious to learn about this new pattern. To stay ahead of the game, I read a lot of articles about microservice architecture, spoke to technology leaders from my network, and studied applicable use cases. At this point, I truly believed in microservices architecture and was convinced the monolith was going away. From there on, every company I have worked for has either adopted, or was in the process of adopting, a microservices architecture. However, in a few of those companies the leadership team could not convince the organization why they were going down the microservices path. The general answer was that “Every other company is doing this and people are presenting about microservices as a game changer at every conference, so let’s do this.” Having worked for multiple corporations in various business domains by providing architecture and design support, I see that it takes a great amount of patience, time, and experience to re-architect existing monolithic apps into microservices architecture.

早在2014年，我担任一家公司的软件工程主管，该公司正在通过采用微服务架构进行数字化转型。 在我耳中， 数字 ， 转换和微服务这些词都是音乐。 当时，作为一名工程主管(我目前是解决方案架构师)，我很想了解这种新模式。 为了保持领先地位，我阅读了很多有关微服务架构的文章，与我的网络的技术负责人进行了交谈，并研究了适用的用例。 在这一点上，我真正相信微服务架构，并确信整体将消失。 从那时起，我工作过的每家公司都采用或正在采用微服务架构。 但是，在其中的一些公司中，领导团队无法说服组织为什么他们选择微服务。 普遍的回答是： “其他公司都在这样做，而且人们在每次会议上都将微服务作为改变游戏规则的方式进行介绍，所以让我们这样做。” 通过提供架构和设计支持为多个公司在各个业务领域中的工作，我发现将现有的单片应用程序重新架构为微服务架构需要大量的耐心，时间和经验。

Before we get into my five key takeaways from using microservices, let us take a step back. So what is a microservice? According to one definition, there is actually no standard definition for this architecture style, but there are certain characteristics “around organization, around business capability, automated deployment, intelligence in endpoints, decentralized control of languages and data.” In my opinion, if a company has to exhibit all the above characteristics to use microservices, then we are not just talking about technology transformation, but also a big cultural change within the organization.

在开始使用微服务的五个关键要点之前，让我们退后一步。 那么什么是微服务？ 根据一个定义 ，实际上没有关于这种体系结构样式的标准定义，但是具有某些特征“围绕组织 ，围绕业务能力 ， 自动化部署 ， 端点中的智能， 对语言和数据的分散控制 ”。 我认为，如果一家公司必须展现出上述所有特征才能使用微服务，那么我们不仅在谈论技术变革，而且在组织内部发生重大的文化变革。

Now, below are five takeaways from my experience in working with microservices:

现在，以下是我在微服务方面的经验中获得的五个收获：

＃1 —您好产品！ (再见项目) (#1 — Hello Product! (Bye bye Project))

In the traditional software approach, the development team builds a monolithic piece of software and the production support team manages it. In this approach, the new owner (the production support team) often does not have complete knowledge of what went into building the component (such as code logic, technology used, etc…). Their core work is to ensure the production system that meets business needs is up and running. There is usually no defined efficient communication path among the teams. Issues with production systems will either lead to a rollback to a restore point or a fast short-term fix. Sometimes a small production code issue will trigger a whole new process. That adds delays as the problem usually has to be resolved by the original development team.

在传统的软件方法中，开发团队将构建一个整体的软件，而生产支持团队将对其进行管理。 在这种方法中，新所有者(生产支持团队)通常不完全了解构建组件的过程(例如代码逻辑，使用的技术等)。 他们的核心工作是确保满足业务需求的生产系统正常运行。 团队之间通常没有定义有效的沟通路径。 生产系统的问题将导致回滚到还原点或快速的短期修复。 有时，一个小的生产代码问题将触发一个全新的过程。 这增加了延迟，因为问题通常必须由原始开发团队解决。

There is a huge amount of risk if you approach microservices with a waterfall mentality (up front design, centralized process over release schedule, build and deploy). You will probably end up with a much more complex system without enjoying any of the benefits promised by microservices.

如果您以瀑布般的心态来处理微服务(前期设计，超过发布计划的集中式流程，构建和部署)，则存在巨大的风险。 您可能最终会得到一个更加复杂的系统，而无法享受微服务所承诺的任何好处。

In the microservices world, you will often hear the word “product”, not project. In this approach, the stakeholders (Users, Program, Product, Tech) work for a common goal, The Product. Product-mode differs from the project-approach right from funding to software delivery through maintenance. Product has a direct relationship to business capabilities offered. And unlike in the traditional approach where multiple teams are involved in building a single monolithic application, the microservice model allows one team to take full responsibility to build and manage this small unit of software. In product-mode teams are stable, cross-functional, and outcome-oriented; they ideate-build-run. Each team is a single department with a unified reporting hierarchy that builds small chunks of independent software units according to the roadmap. The teams in one tier consider the other tier teams as their customers (internal) and collaborate with them to solve business problems, not work in a scope-delivery manner. Since the engineering team working in product-mode understands the software behaviour in production, any issues will be addressed with immediate resolution, avoiding delays.

在微服务世界中，您经常会听到“产品”一词，而不是项目。 在这种方法中，利益相关者(用户，程序，产品，技术)致力于一个共同的目标， 即产品 。 产品模式从资金到软件交付再到维护，都不同于项目方法。 产品与提供的业务功能有直接关系。 与传统方法不同，在传统方法中，需要多个团队来构建单个整体应用程序，而微服务模型则允许一个团队完全负责构建和管理这一小部分软件。 在产品模式下，团队是稳定的，跨职能的和以结果为导向的； 他们构思建设运行。 每个团队都是具有统一报告层次结构的单个部门，该部门根据路线图构建小块独立软件单元。 一层中的团队将另一层团队视为他们的客户(内部)，并与他们协作以解决业务问题，而不是以范围交付方式工作。 由于以产品模式工作的工程团队了解生产中的软件行为，因此可以立即解决所有问题，避免延迟。

Here at Capital One, the You Build You Own (YBYO) concept allows teams to take full responsibility to design, build, test, and deploy software in production. Engineering teams collaborate with products and interact with users directly, with continuous feedback from those users helping the teams to build high quality products.

在“首都一号”， 您可以自己构建(YBYO)概念，团队可以全权负责设计，构建，测试和部署生产环境中的软件。 工程团队与产品协作并直接与用户互动，这些用户不断提供反馈，帮助团队构建高质量的产品。

Takeaway: Smaller scope allows teams to better build and manage microservices. Product-mode enables partnership, ownership and builds strong relationships with end-users.

要点：较小的范围使团队可以更好地构建和管理微服务。 产品模式可以实现伙伴关系，所有权并与最终用户建立牢固的关系。

＃2 —更大的自由和责任感：大胆思考，以“微”服务构建 (#2 — More Freedom and Responsibility: Think Big, Build With “Micro” Services)

Before joining Capital One, I worked at another company on a team, building a product catalog service for their company’s eCommerce website. The company was following a microservices approach and this product catalogue service was designed to provide a list of products to the end-user based on a request criteria. As my team had control over data and the catalog database, we chose Java and SpringBoot to build our service (we were comfortable with the programming language and more libraries were available to use). Finally, the service was exposed on an API Gateway for end-users.

加入Capital One之前，我曾在另一家公司工作过，为他们公司的电子商务网站构建产品目录服务。 该公司正在采用微服务方法，该产品目录服务旨在根据请求标准向最终用户提供产品列表。 由于我的团队可以控制数据和目录数据库，因此我们选择了Java和SpringBoot来构建我们的服务 (我们对编程语言很满意，可以使用更多的库)。 最后，该服务在面向最终用户的API网关上公开。

Similarly, there were several other teams in the company that built their own services using different technologies. From a product point of view, each feature was supported by various services built on heterogeneous platforms. This model solved a major problem with having to recruit and train teams to build monolithic apps using the same tech stack. In this microservices model, each team could choose tools that were apt for our business needs, and hire new teammates accordingly.

同样，公司中还有其他几个团队使用不同的技术来构建自己的服务 。 从产品的角度来看，每种功能都由异构平台上构建的各种服务支持。 该模型解决了一个主要问题，即必须招募和培训团队以使用相同的技术堆栈构建整体应用程序。 在这种微服务模型中，每个团队都可以选择适合我们业务需求的工具，并相应地雇用新的团队成员。

Microservices is an architecture style where components of a business application are built via services. Each service is a logical software unit of business process which is independent of other services. The freedom (no-dependency on other services, choice of technology, etc.) in this approach opens the doors for exploring new technologies, building local software components, and designing based on the scope defined for the service.

微服务是一种体系结构样式，其中业务应用程序的组件是通过服务构建的。 每个服务都是业务流程的逻辑软件单元，独立于其他服务。 这种方法的自由(不依赖于其他服务，技术选择等)为探索新技术，构建本地软件组件以及基于针对服务定义的范围进行设计打开了大门。

At Capital One, software products are aligned with business capabilities. The various lines of businesses (LOBs) build and manage their own products and there is a cross-functional line of business that is focused on building and managing enterprise products such as data lakes and platforms that cater to the needs of all LOBs.

在Capital One，软件产品与业务功能保持一致。 各种业务线(LOB)构建和管理自己的产品，并且存在跨职能的业务线，其重点是构建和管理企业产品，例如满足所有LOB需求的数据湖和平台。

Takeaway: The underlying principle of loose coupling and high cohesion allows teams to build multiple products that solve bigger business problems

要点：松散耦合和高凝聚力的基本原理使团队可以构建多种产品来解决更大的业务问题

＃3 —实施是关键：RESTful服务可使您的生活不安 (#3 — Implementation is Key: RESTful services can make your life restless)

Microservices architecture is really micro-component architecture. The micro is about fine-grained components, but not about granularity of the interfaces exposed. Microservices are components whereas APIs are interfaces and not all microservices components expose APIs. I can have the same number of APIs exposed transitioning from monolith to microservice architecture. In the transition to microservices, the initial planning may take days or months, which in turn will add to initial upfront costs. This may require more teams to collaborate and work to break down large applications into microservices. There is a continuous risk of over engineering, and this may lead to the creation of more microservices than needed, which in turns adds to the complexity of the architecture.

微服务架构实际上是微组件架构。 微型与细粒度的组件有关，但与暴露的接口的粒度无关。 微服务是组件，而API是接口，并非所有微服务组件都公开API。 我可以使用相同数量的从单片到微服务架构过渡的API。 在向微服务的过渡中，初始计划可能需要几天或几个月的时间，这反过来会增加初始的前期成本。 这可能需要更多的团队协作才能将大型应用程序分解为微服务。 存在过度工程的持续风险，这可能导致创建比所需更多的微服务，从而增加了体系结构的复杂性。

A company I worked for before joining Capital One identified a few monolithic business applications that could be migrated to a microservice architecture. There was no change in the product’s vision, as the business functionality of the monolith did not change. More teams were recruited, anticipating that services would need to be owned by these teams. Services were deployed as per the corporate release schedule and the infrastructure team still owned production systems as their process was not impacted by this initiative. Two years after the program started, not much progress had been made and the organization ran out of budget.

在加入Capital One之前，我曾为之工作的一家公司确定了一些可以迁移到微服务架构的整体业务应用程序。 产品的愿景没有改变 ，因为整体的业务功能没有改变。 招募了更多的团队，预计这些团队将需要拥有服务。 根据企业发布时间表部署了服务，并且基础架构团队仍拥有生产系统，因为其过程不受此计划的影响。 该计划开始两年后，进展不大，该组织预算用光。

This is one of many examples where teams within companies should communicate better over microservices implementation. It’s not just app development and new technology that brings digital transformation, a lot of work needs to be done in product analysis, budget estimates, architecture, redesign of deployment procedures, infrastructure scaling, and other relevant processes. Transition to microservices involves time, money, and big changes in how you see business problems.

这是公司内的团队应通过微服务实现更好地沟通的众多示例之一。 带来数字化转型的不仅是应用程序开发和新技术，还需要在产品分析，预算估算，体系结构，部署程序的重新设计，基础架构扩展以及其他相关过程中进行大量工作。 向微服务的过渡涉及时间，金钱以及您如何看待业务问题方面的重大变化。

Takeaway: Microservice is not just an architecture style, it demands a cultural shift that impacts every team in the organization.

总结：微服务不仅是一种体系结构风格，它还需要文化上的转变，从而影响组织中的每个团队。

＃4 —长期利益：复杂且昂贵，但具有弹性和可扩展性 (#4 — Long Run Benefits: Complex and Expensive, but Resilient and Scalable)

The microservices journey will lead to the creation of a lot of products, services, and teams. Organizations have to have a solid roadmap before taking on this complex architecture. That is because strong enterprise products are required to support and bring together those various teams working in a microservice style. For instance, tools that support API documentation, and collaborative tools such as source control management, issue trackers, and tools enable automatic deployments.

微服务的旅程将导致创建许多产品，服务和团队。 在采用这种复杂的体系结构之前，组织必须有坚实的路线图。 这是因为需要强大的企业产品来支持以微服务方式工作的各个团队并将其聚集在一起。 例如，支持API文档的工具以及诸如源代码管理，问题跟踪器和工具之类的协作工具可实现自动部署。

Engineering teams build services and expose them as APIs on an API Gateway. These API Gateways are like a marketplace for REST APIs and the backbone of the organization for daily business operations. Once an organization gets on the right track with a microservices approach, a continuous stream of services is created, upgraded, replaced etc., and engineers may not know where every service is located. A Service Discovery system allows services to be detected automatically and help them find each other.

工程团队构建服务并将其作为API公开在API网关上。 这些API网关就像是REST API的市场，也是日常业务运营的组织骨干。 一旦组织采用微服务方法走上了正确的轨道，便会创建，升级，替换等连续的服务流，并且工程师可能不知道每个服务的位置。 服务发现系统允许自动检测服务并帮助它们找到彼此。

To achieve better performance and fault isolation, components of a microservice need dedicated infrastructure. A microservice should have its own release schedule and should be allowed to deploy to production at any time without depending on others. The choice of an effective tool that supports continuous, real-time monitoring and analysis of the microservices is an essential. APIs are the interfaces to the microservice world so API logging, performance monitoring, and security are also key for the progress of IT services in the organization.

为了获得更好的性能和故障隔离，微服务的组件需要专用的基础架构 。 微服务应具有自己的发布时间表，并应允许其随时部署到生产环境，而无需依赖其他服务。 选择支持连续，实时监视和分析微服务的有效工具至关重要。 API是微服务世界的接口，因此API日志记录，性能监视和安全性也是组织中IT服务进步的关键。

Resilient Microservices can be built following various patterns such as the Retry Pattern, which enables an application to handle transient failures when it tries to connect to a service or network resource by transparently retrying a failed operation. The Circuit Breaker pattern, allows for handling faults gracefully when errors occur connecting to a remote service or resource. This will avoid cascading failure in the microservice ecosystem, which can improve the stability and resiliency of an application. Each service in a microservice is a separate component and every single function or service can be scaled up without having to scale the entire application. The multiple instances of critical services can be deployed for high availability and better performance without impacting the performance of other services.

可以按照各种模式(例如重试模式)来构建弹性微服务 ，该模式使应用程序可以通过透明地重试失败的操作来尝试连接到服务或网络资源时处理瞬态故障。 断路器模式允许在连接到远程服务或资源时发生错误时优雅地处理故障。 这将避免微服务生态系统中的级联故障，从而可以提高应用程序的稳定性和弹性。 微服务中的每个服务都是一个独立的组件，每个功能或服务都可以扩展，而不必扩展整个应用程序。 可以部署关键服务的多个实例以实现高可用性和更好的性能，而不会影响其他服务的性能。

Takeaway: Though the initial phase of transition to microservices takes a lot of resources and effort, with time and dedication and the help of automation tools, businesses can reap benefits and will be able to deliver quality products to market quickly.

要点：尽管向微服务过渡的初始阶段需要大量资源和精力，但是时间和精力以及自动化工具的帮助，使企业可以从中受益，并能够将优质的产品快速推向市场。

＃5 —微服务并非适合所有人 (#5 — Microservices Are Not for Everyone)

Microservice may not be suitable for every business or use case. This includes ones where a team has to build a simple application with few features or are unable to break large monoliths into smaller pieces or did not understand the trade-offs that come with the microservice architecture style. Additionally, some businesses may not be provisioned with rapid development and application deployment capabilities or do not need to constantly monitor applications or businesses for which the time for recovery (in case of failure) is high with minimum business impact.

微服务可能并不适合所有业务或用例。 这包括团队必须构建具有很少功能的简单应用程序，或者无法将大型整体拆分成较小的块，或者不了解微服务体系结构样式所带来的取舍的情况。 此外，某些企业可能未配备快速开发和应用程序部署功能，或者不需要持续监视恢复时间(如果发生故障)的时间较长且对企业的影响最小的应用程序或企业。

Microservices are only a tool, and like all tools, they are not a solution to every business problem. Business takes precedence over everything, the underlying systems can adapt to any architecture pattern, whether they are monoliths or microservices. Before deciding on microservices, every company has to understand their business needs and review the trade offs before making a decision on microservices.

微服务只是一种工具，与所有工具一样，它们并不是解决每个业务问题的解决方案。 业务优先于一切，底层系统可以适应任何体系结构模式，无论是整体还是微服务。 在决定使用微服务之前，每家公司必须先了解其业务需求，并在权衡利弊后再决定使用微服务。

Capital One invested a lot of time and effort in studying the application of microservices before going all-in with a cloud and microservices architecture. The able leadership, visionary product teams, and the skilled engineering teams collaborated to help Capital One achieve the goal of becoming a technology leader in banking.

在完全采用云和微服务架构之前，Capital One在研究微服务的应用上投入了大量时间和精力。 精干的领导，富有远见的产品团队和技术精湛的工程团队合作，帮助Capital One实现了成为银行技术领导者的目标。

Takeaway: With microservices there is no free lunch.

要点：使用微服务没有免费的午餐。

With microservices architecture, there is a huge surge in infrastructure needs, cost and complexity, why are companies adopting microservices? Large companies with large customer bases thrive by delivering quality products to customers within a short amount of time. Their systems need to be always up and running, serving customers distributed across various geographies. Microservices are an approach that helps achieve this goal. In today’s world, with the advent of cloud-native infrastructure, automation of the delivery pipeline (DevOps), and adoption of containers, companies should look into the advantages of microservices.

使用微服务架构，基础架构需求，成本和复杂性激增， 为什么公司采用微服务？ 具有大客户群的大公司通过在短时间内向客户提供优质产品而蓬勃发展。 他们的系统需要始终保持运行状态，为分布在各个地区的客户提供服务。 微服务是一种有助于实现此目标的方法。 在当今世界中，随着云原生基础架构的出现，交付管道(DevOps)的自动化以及容器的采用，公司应该研究微服务的优势。

I would like to affirm that you should not adopt something just because others are doing some cool stuff with it. Instead, invest the time and effort to understand this architecture pattern and its relevance to your company before adopting microservices. I hope my key takeaways have left you feeling more prepared for your microservices journey.

我想肯定的是，您不应该仅仅因为其他人正在做一些很酷的事情而采用某些东西。 相反，在采用微服务之前，请花费时间和精力来了解这种架构模式及其与贵公司的相关性。 希望我的主要收获使您对微服务的旅程有所准备。

Originally published at https://www.capitalone.com.

最初在 https://www.capitalone.com上 发布 。

DISCLOSURE STATEMENT: © 2020 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.

披露声明：©2020 Capital One。 观点是个别作者的观点。 除非本文中另有说明，否则Capital One不与任何提及的公司有附属关系或认可。 使用或显示的所有商标和其他知识产权均为其各自所有者的财产。