客户旅程_我们进入微服务世界的旅程-以及从中学到的东西。

客户旅程

by Ignacio Salazar Williams

通过伊格纳西奥·萨拉萨尔·威廉姆斯(Ignacio Salazar Williams)

我们进入微服务世界的旅程-以及从中学到的东西。 (Our journey into the world of Microservices — and what we learned from it.)

I know, I know everyone is talking about Microservices. It’s the a pattern that will lead us to the future of architecture, say those who talk about Digital Transformation. It’s the “Destroyer of Monoliths” for others, the silver bullet that will solve all of our architectural problems.

我知道，我知道每个人都在谈论微服务。 那些谈论数字化转型的人士说，这种模式将引领我们走向建筑的未来。 对于其他人来说，这是“巨石的毁灭者”，它将解决我们所有的建筑问题。

Let me tell you something about microservices. They really are something, but it is not just like **puff** **some magic** **Fairy dust** here is the solution to all our problems. I’m not going to tell you more about them as a pattern, but rather I’ll try to tell this story (my story) as best as I can. I’ll discuss how this concept, this pattern, was developed in reality, under certain circumstances. I call it The Micro-Armageddon.

让我告诉您一些有关微服务的信息。 它们确实是某种东西 ，但是不仅仅像** ** **一些魔术** **尘埃**一样，这是我们所有问题的解决方案。 我不会以模式来向您介绍更多有关它们的信息，但我会尽力讲这个故事(我的故事)。 我将讨论在某些情况下实际上是如何发展这种概念(这种模式)的。 我称它为Micro-Armageddon 。

On a daily basis, on my team, there were things that were out of our reach and led to problems. But it was just a matter of seeing the big picture, and working with the mentality to continually improve our components until we reached the quality standards that we as a team had.

每天，在我的团队中，有些事情是我们无法企及的，并且会导致问题。 但这只是看大图，并与心态一起不断改进我们的组件，直到我们达到团队的质量标准为止。

So please follow me along this journey of goods and bads, laughs and tears, and lots of “why the heck did we do this in the first place?”

因此，请跟随我走过货物，坏物，笑声和眼泪以及许多“为什么我们一开始就这样做呢？”的旅程

TL;DR?

TL; DR？

TL;DR?I know it seems like a lot, but let me tell you something. If you are looking to learn from another’s mistakes about Microservices, I do highly recommend that you read this article completely. But if not, you can skip to the memes — at least it’ll make you laugh!

TL; DR？ 我知道这看起来很多，但是让我告诉你一些事情。 如果您想从别人的微服务错误中学习，我强烈建议您完整阅读本文。 但是，如果没有，您可以跳到模因-至少它会让您发笑！

一点背景 (A little bit of background)

Let’s start with the basics. There was me (Hi!), a recently graduated student of computer science, who just got hired for some consulting (the wild west of jobs). I got assigned to this project for one of our clients (in their offices), in which our team was in charge of applying a Digital Transformation to their business. Therefore, Microservices were involved. (Now that I’m more experienced in the field, I hear these two concepts very often together.)

让我们从基础开始。 有我(嗨！)，他是计算机科学的新近毕业的学生，​​刚刚被聘请做一些咨询(工作的荒野)。 我被分配给了一位客户(在他们的办公室)这个项目，我们的团队负责将数字化转型应用于他们的业务。 因此，涉及微服务。 (现在，我在该领域更有经验，因此我经常会经常听到这两个概念。)

We were using Node.js as the back-end programming language (ohhhh yeeees), so that meant we were also using Express as a default framework to expose the APIs. Also, it’s important to add to the mix that we were using the Agile methodology of Scrum (you’ll see why I brought up this point shortly).

我们正在使用Node。 js作为后端编程语言(是的)，这意味着我们还使用Express作为默认框架来公开API。 同样，添加到我们正在使用Scrum敏捷方法的组合中也很重要(您很快就会看到为什么提出这一点)。

团队 (The Teams)

We were divided in two big groups: the first one, the one that I was part of, was the Architecture Team. We were in charge of orienting the teams and spreading the word about Microservices. The second team, the Dev Team, was in charge of developing the products desired by the business. There were multiple teams working on different products at the same time, along with working on the Microservices.

我们分为两大类：第一个是我所属的团队 ，是架构团队。 我们负责指导团队，并传播有关微服务的信息。 第二个团队是开发团队，负责开发业务所需的产品。 有多个团队同时在开发不同的产品，同时也在开发微服务。

The Architecture team looked something like this:

架构团队看起来像这样：

• 1 Senior Manager (ours)
  1名高级经理(我们)
• 2 Managers (1 ours, 1 theirs)
  2位经理(我们1位，他们1位)
• 10 Architects (6 ours, 4 theirs)
  10位建筑师(我们6位，他们4位)
• 2 in charge of big data
  2负责大数据
• 3 in charge CI/CD
  3位主管CI / CD
• 3 in charge of security
  3负责安全
• 2 in charge of back/front end development architecture
  2分管后端/前端开发架构

Each Dev Team looked something like this:

每个开发团队看起来都是这样的：

• 1 Scrum Master (another consulting)
  1个Scrum Master(另一个咨询)
• 1 Product Owner (client side)
  1个产品负责人(客户端)
• 4 Developers (2 ours, 2 theirs)
  4个开发人员(我们2个，他们2个)
• 1 QA
  1个质量检查
• 1 UX
  1个用户体验
• 1 Architect (client side)
  1位建筑师(客户端)

I know that this already sounds bad, mixing it all up, but don’t you worry — for us, it was an opportunity to make things right…

我知道这听起来很糟糕，将所有因素混在一起，但是您不用担心-对我们来说，这是一个使事情正确的机会……

开发人员背景技能 (Developer background skills)

None of us was born being a skilled developer, all of us were like a monkey trying to compile a basic “Hello World”. Felipe Lazo

我们每个人都不是一个熟练的开发人员，而是像猴子一样试图编译基本的“ Hello World”。 费利佩·拉佐(Felipe Lazo)

Our team members had all kind of backgrounds, from the the ones that barely know how their own computer worked, to the ones that probably came from NASA. Some people had worked with COBOL, Java, JavaScript, C, Python, and others, and while others had worked with no languages at all.

我们的团队成员具有各种背景，从几乎不了解自己计算机工作原理的背景到可能来自NASA的背景。 有些人使用过COBOL，Java，JavaScript，C，Python等，而其他人则完全不使用任何语言。

So it would be easy to understand if some team members weren’t especially good at developing good code and structures, as many of them had no previous background in the subject. Again, there were others that had some experience. So it was perfectly fine to have all these different profiles, but it was up to us to make the best of them. We couldn’t see it as a weakness, but an opportunity for us as a team (specially when you work in an agile environment).

因此，如果一些团队成员不是特别擅长于开发良好的代码和结构，这很容易理解，因为其中许多人以前没有该主题的背景。 同样，还有其他人也有一些经验。 因此，拥有所有这些不同的配置文件是完全可以的，但是我们需要充分利用它们。 我们不能认为这是一个弱点，而是我们作为一个团队的机会(特别是当您在敏捷环境中工作时)。

目标 (The Objective)

Here we were with the goal of implementing Microservices as a Back-End solution to the integration of legacy components that our client had. We planned to expose them as simple APIs in order that the teams could integrate them into their applications.

在这里，我们的目标是将微服务作为后端解决方案实施，以集成客户拥有的旧组件。 我们计划将它们公开为简单的API，以便团队可以将它们集成到他们的应用程序中。

Here were the initial requirements of our Microservices:

这是我们的微服务的初始要求：

• They had to Consume a SOAP Service and return the result as JSON. I know that for most of you (and including me), it’s going to sound really bad. But it had to be like this, because the Microservices weren’t authorized to connect to the Data Layer directly, so they had to go through SOAP [Client initial requirement].
  他们必须使用SOAP服务并将结果作为JSON返回。 我知道对于你们大多数人(包括我)来说，这听起来真的很糟糕。 但是必须这样，因为微服务无权直接连接到数据层，因此它们必须通过SOAP [客户初始要求]。
• It had to LOG all the data that produced the Microservices into the brand new DataLake.
  它必须将产生微服务的所有数据记录到全新的DataLake中。
• Basic Authentication.
  基本身份验证。
• Get them to be as fault-proof possible.
  让它们尽可能地防故障。

To these requirements, we had to add:

对于这些要求，我们必须添加：

• the quality that we desired through Unit Testing (including our ambitious coverage standard of 90%)
  通过单元测试所需的质量(包括我们雄心勃勃的90％覆盖率标准)
• Static Code Analysis
  静态代码分析
• Performance test
  性能测试
• and some kind of Security Check.
  以及某种安全检查。

All of this had to be manually checked locally and then checked through a rigorous Pipeline (CI/CD). I say rigorous, but it wasn’t a blocking one. It still allowed teams to deploy Microservices even though one of the jobs failed. But don’t ever do this, or at least know the consequences.

所有这些都必须在本地手动检查，然后通过严格的管道(CI / CD)进行检查。 我说的很严格，但这不是一个阻碍。 即使其中一项工作失败，它仍然允许团队部署微服务。 但是永远不要这样做，至少不要知道后果 。

So far, we didn’t have many problems at all. This sounded pretty good for a basic setup in order to develop Microservices. We had DevOps, we were all in the same place, we had our methodology, we had our pattern, and we had a fantastic run-time (Node.js) that would allow us to build and follow the rules step by step to make this project a masterpiece. Well, at least that was what we thought…

到目前为止，我们根本没有很多问题。 对于开发微服务的基本设置来说，这听起来不错。 我们有DevOps，我们都在同一个地方，我们有我们的方法，我们有我们的模式，而且我们有一个很棒的运行时(Node.js)，它使我们可以逐步构建和遵循规则，以使这个项目的杰作。 好吧，至少那是我们的想法……

哦，男孩，犯了错误 (Oh boy, mistakes were made)

Check out this fairly accurate picture of the architecture team trying to save the Microservices from their doom. Why did this happen, you may ask? Well, this can happen when you give the freedom to multiple teams to develop their own Microservices in an Agile environment. Trouble arises when you don’t give any other explanation of what Microservices actually are, what they do, what is their purpose, how we govern them, and, most importantly, how big they have to be.

查看架构团队试图从微服务的厄运中挽救它们的这张相当准确的图片。 您可能会问，为什么会发生这种情况？ 好吧，当您允许多个团队在敏捷环境中开发自己的微服务时，就会发生这种情况。 当您不对微服务实际上是什么，它们做什么，它们的目的是什么，我们如何管理它们，以及最重要的是它们必须具有多大的其他原因不做任何解释时，就会出现麻烦。

And to top all of that off, at the beginning of the project we didn’t have any reliable Version Control Software except Subversion. Meanwhile we were waiting for Git to be installed on premise.

最重要的是，在项目开始时，除了Subversion之外，我们没有任何可靠的版本控制软件。 同时，我们正在等待在内部安装Git。

A problem that we saw often in many immature teams was that instead of trying to put out the fire, they just spread it out even more by duplicating the Microservices and beginning to build over them. This made them even bigger and they contained useless and duplicate content.

在许多不成熟的团队中，我们经常看到的一个问题是，他们没有试图扑灭大火，而是通过复制微服务并开始在它们之上进行构建来扩大火势。 这使它们更大，并且包含无用和重复的内容。

• Microservice Clients (Team A, B and C work on it)

  微服务客户端 (团队A，B和C在此上工作)

  — Team B is tired of all the merges, and all the fighting for who is responsible of what, plus the deployment of it.

  —团队B厌倦了所有合并，为谁负责什么的所有战斗以及部署。

• Microservice Loans-Clients (Team B)

  微服务贷款客户 (B组)

  — Team B copies the exact state that they were working on in the

  —团队B复制了他们在

  Clients Microservices. This exposes and maintains more and more useless endpoints on top of their actual useful ones.

  客户端微服务 。 除了它们的实际有用端点之外，这还暴露并维护了越来越多的无用端点。

So here we were. How the hell (actual hell) do we solve all of these problems? Well, this is what we did.

所以我们到了。 我们该如何解决所有这些问题？ 好吧，这就是我们所做的。

病征 (The Symptoms)

We clearly couldn’t keep going with all of this mess, so we put on our white doctors’ coats, sterilized the room, and did an autopsy of what we had. We identified the symptoms of our unavoidable doom, prioritized the most important ones, and tried to win small victories that would allow us to take control over the situation.

我们显然无法忍受所有这些混乱，所以我们穿上了白色医生的外套，对房间进行了消毒，并对我们所拥有的进行了尸检。 我们确定了不可避免的厄运的症状，将最重要的厄运排在了优先位置，并试图赢得小小的胜利，使我们能够控制局势。

Small victories allow you not only to prove that you know about the subject, but they also let the teams know that something can be done to improve their daily work.

取得小的胜利，不仅可以证明自己了解这一主题，还可以使团队知道可以做些事情来改善他们的日常工作。

迷你独占AKA宏服务 (Mini-Monolith A.K.A Macroservices)

Wait what? We were talking about microservices…

等等什么 我们在谈论微服务…

I bet you have read multiple times about the S.O.L.I.D. principle, about having smart compact pieces that have the famous single responsibility principle.

我敢打赌，您已经多次阅读有关SOLID的信息 。 原理，即拥有具有著名的单一责任原则的精巧紧凑的物件。

What we had was nothing like that. This is why I called them Macroservices, after I saw what was happening.

我们所拥有的不是那样。 这就是为什么在我看到发生了什么之后我将它们称为Macroservices的原因。

Just picture this: in a simple domain, let’s call it Users, there were around 15 POST Operations in the same **cough** “Microservice.” Every single one had a different purpose under the same domain and used custom made libraries for each one of them. Plus we had all the unit and performance tests spread around in there. So it was mayhem. It was pretty much something like this:

想象一下：在一个简单的域中，我们称其为Users ，在同一“ 咳嗽 ”“微服务”中大约有15个POST操作。 每个人在同一域下都有不同的目的，并为每个人使用定制的库。 另外，我们在那里进行了所有单元测试和性能测试。 所以那是混乱的。 差不多是这样的：

.
├── app --The whole MS is in here
│   ├── controllers --All the controllers of the domain
│   │   ├── dummies
│   │   │  └── ** All the dummies for each controller **
│   │   ├── xsl
│   │   │   └── ** All xsl configuration for each controller **
│   │   ├── Controller1.js
│   │   ├── Controller2.js
│   │   ├── Controller3.js
│   │   ├── Controller4.js
│   │   ├── Controller5.js
│   │   └── **Literally 20 more controllers**
│   ├── functions --All the functions of the MS
│   │   ├── function1.js
│   │   ├── function2.js
│   │   ├── function3.js
│   │   └── function4.js
│   ├── properties --All the properties of the MS
│   │   ├── propertie1.js
│   │   └── propertie2.js
│   ├── routes --All the routes of the MS
│   │   ├── routes_useSecurity.js
│   │   └── routes_withoutSecurity.js
│   ├── services --Extra services that were consumed
│   │   ├── service1.js
│   │   └── service2.js
│   └── xsl
│      └── **A bunch of XSL to do transformations**
├── config --"Global" configurations
│   ├── configSOAP.js
│   ├── configMS.js
│   ├── environments.js
│   ├── logging.js
│   ├── userForBussinessA.js
│   └── userForBussinessB.js
├── package.json
├── README.md
├── test--All the tests
│   ├── UnitTesting
│   │   └── Controllers
│   │       └── ** All the 25 tests in theory **
│   └── PerformanceTest
│       ├── csv_development.txt
│       ├── csv_QA.txt
│       ├── csv_production.txt
│       ├── performance1.jmx
│       └── performance2.jmx
├── server.js --Express Server
├── serverKey.keytab
├── sonarlint.json
├── encryptor
├── ** Around 10 more useless files **
└── Dockerfile

First of all, this had to stop because it was ungovernable. Teams were fighting, because in order to test something in the DEV environment (which they did often), they had to go through the CI/CD pipeline. By that time in the project, it certainly wasn’t perfect.

首先，这是必须停止的，因为它不可治理。 团队之争是因为要在DEV环境中测试某些东西(他们经常这样做)，他们必须经过CI / CD管道。 到那时在项目中，它当然还不是完美的。

So If team A modified Controller1, they had go to through the pipeline, with a high chance of failing (and deployment would then fail, too). They would go over and over again until they succeeded. Therefore, all the teams tried to race so they wouldn’t be the last that deployed. Because if something failed in that deploy, fingers were pointed. It meant that the team did something wrong and broke it.

因此，如果团队A修改了Controller1，则他们必须通过管道进行操作，极有可能失败(然后部署也将失败)。 他们会一遍又一遍，直到成功。 因此，所有车队都试图参加比赛，因此不会成为部署的最后一支。 因为如果在该部署中发生故障，则需要指出。 这意味着团队做错了事并打破了它。

Fun right? A healthy environment for all developers. Who doesn’t want to be there… well, NOT ME!

好玩吧？ 所有开发人员的健康环境。 谁不想在那里……好吧，不是我！

是时候重新开始 (It was time to have a fresh start)

We needed to start fresh and do things right. Take control of who was doing what, and make them responsible. But we had to be fair: we were not going to make a team responsible for a whole domain that contained 15 operations, tests, deployments, and so on. Nobody wanted that.

我们需要重新开始并做正确的事。 控制谁在做什么，并使他们负责。 但是我们必须公平地说：我们不会组成一个团队来负责包含15个操作，测试，部署等的整个领域。 没有人想要。

You know, we are agile, agile people do agile things. We don’t need to waste our precious time on these fights of who owns what, raising blockers, and pointing fingers ** rolling eyes**.

要知道，我们是敏捷的，敏捷的人会做敏捷的事情。 我们不需要浪费宝贵的时间在那些谁拥有什么东西，举起障碍物以及手指** 滚动 **的斗争中。

步骤1：调整微服务大小 (Step 1: Sizing Microservices)

I’m going to make a bold assertion and say that the largest number of operations for any Microservices must follow the CRUD standard. Forget about thinking about how big the Microservices should be.

我将大胆地断言 ，任何微服务的最大操作数必须遵循CRUD 标准。 不用考虑微服务应该有多大。

Following this rule will give you peace of mind at night, knowing that at most — at any given time — you’ll only need to have 4 operations in any subdomain. And that’s it.

遵循此规则将使您晚上安心，并且知道最多(在任何给定时间)在任何子域中只需进行4次操作。 就是这样。

This means:

这表示：

POST —创建 (POST — Create)

CREATE procedures are the insertion of new data as the finality of the Microservices.

CREATE过程是作为微服务的终结性插入新数据。

获取—阅读 (GET — Read)

READ procedures read the data needed by the client.

READ程序读取客户端所需的数据。

PUT —更新 (PUT — Update)

UPDATE procedures modify records without overwriting them.

UPDATE过程修改记录而不覆盖它们。

删除—删除 (DELETE — Delete)

DELETE procedures delete where specified.

DELETE过程在指定的地方删除。

Using this rule allowed us to make more compact, smart, and standard Microservices. It will grant us the upper hand when the time comes to divide the Microservices, for example.

使用此规则可以使我们制作更紧凑，更智能和更标准的微服务。 例如，当需要分割微服务时，它将为我们提供优势。

Let’s say that I have my Clients Microservice in a banking Domain, and suddenly I see that I not only need our credit clients but also our loaners. Well, that’s easy. I just divide our Domain Clients into two Subdomains: Credit-Client and Loan-Client, and from there you can see how everything starts to fit into place.

假设我在银行领域中拥有我的客户微服务 ，突然间我发现我不仅需要我们的信贷客户 ，还需要我们的借款人。 好吧，那是 简单。 我只是将我们的域客户分为两个子域： Credit-Client和Loan-Client ，从那里您可以看到一切如何开始到位。

Perfect! We now had proper microservices. It was now up to the client and the team to develop a way to know how to split the Domains, and know their Subdomains.

完善！ 现在，我们有了适当的微服务。 现在，由客户和团队来决定一种方法，以了解如何拆分域并了解其子域。

If only there was a way to do it… **cough** Doman Driven Design.

如果只有一种方法可以做到……咳嗽Doman Driven Design 。

第2步：必须拥有它 (Step 2: Someone has to own it)

Woo-hoo, we had one of our problems fixed, but wait — now I had a bunch of smaller pieces, and everyone was working on them. And I wasn’t going to be responsible for it if it broke.

哇，我们已经解决了一个问题，但是等一下-现在我有一大堆较小的东西，每个人都在研究它们。 如果它破裂，我将不负责。

All I’ll say is: “If you code it, you own it”. And with this powerful wisdom you may say: “Well I know that, everyone knows that.” But no, not everyone knew that, and it is a common mistake. So be smart, and go one step further and make it a rule.

我要说的是：“ 如果您对其进行编码，就拥有它” 。 凭借这种强大的智慧，您可能会说：“我知道，每个人都知道。” 但是，不是，不是每个人都知道这一点，这是一个常见的错误。 因此，要聪明一点，再进一步，并使其成为规则。

Git allows you to develop in peace (if it’s applied well — check the link about Learning to love Git from D. Keith Robinson above), knowing that your code is always going to be up to date. If anyone else wants to improve it, suggest a change, or if they simply need an update, all this has to go through the owner. For the sake of this example, we will say that the owner is the architect of the DEV team who developed it. This works so well in agile environments.

Git可以让您和平发展(如果应用得当，请查看上面D. Keith Robinson的有关学习爱Git的链接)，因为您知道代码始终是最新的。 如果其他任何人想要改进它，建议进行更改，或者他们仅需要更新，则所有这些都必须经过所有者。 为了这个示例，我们将说所有者是开发它的DEV团队的架构师。 这在敏捷环境中效果很好。

步骤3：API端点(命名)和版本控制 (Step 3: API Endpoint (Naming) and Versioning)

The way that you name APIs could save all your developers tons of time and effort. Naming APIs it’s not a game. It could save lives.

API的命名方式可以节省所有开发人员大量的时间和精力。 命名API不是游戏。 它可以挽救生命 。

It’s really important to add value to your Microservices by naming them correctly. If you don’t know what to name them, ask the business and discuss it with your team. Design driven development may help here.

通过正确命名微服务来为其增值非常重要。 如果您不知道该如何命名，请询问业务并与您的团队讨论。 设计驱动的开发可能会有所帮助。

Check out the RESTful API Designing guidelines — best practices for more info here. I could’ve quoted the whole page.

在此处查看RESTful API设计指南-最佳实践，以获取更多信息。 我可以引用整个页面。

步骤4：让我们重组已有的内容 (Step 4: Let’s restructure what we had)

It’s one thing to have the concept right, but how does it look in practice?

拥有正确的概念是一回事，但是在实践中它看起来如何？

The next file tree that I’ll show you gets back to my idea of how much of a follower of the concept of Microservices I am. I’ve made it follow the loose coupling and high cohesion between services concept:

我将向您展示的下一个文件树回到我对微服务概念的追随者的想法。 我使它遵循服务概念之间松散的耦合和高度的凝聚力 ：

.
├── config
│   ├── artillery.js
│   ├── config.js
│   ├── develpment.csv
│   ├── processorArtillery.js
│   ├── production.csv
│   └── qa.csv
├── index.js
├── package.json
├── package-lock.json
├── README.md
├── service
│   ├── getLoans --The operation
│   │   ├── getLoans.config.json --Configuration of the resource
│   │   ├── getLoans.contract.js --Contract test
│   │   ├── getLoans.controller.js --Controller
│   │   ├── getLoans.performance.json --Performance test config
│   │   ├── getLoans.scheme.js --Scheme validator
│   │   ├── getLoans.spec.js --Unit Tests
│   │   └── Util --Local functions
│   │       ├── trimmer.js
│   │       └── requestHandler.js
│   ├── postLoans
│   │   ├── postLoans.config.json
│   │   ├── postLoans.contract.js
│   │   ├── postLoans.controller.js
│   │   ├── postLoans.performance.json
│   │   ├── postLoans.scheme.js
│   │   └── postLoans.spec.js
│   └── notFound
│       ├── notFound.js
│       ├── notFound.performance.json
│       └── notFound.spec.js
├── Util --Global functions
│   ├── headerValidator.js
│   ├── bodyValidator.js
│   ├── DBConnector.js
│   └── BrokerConnector.js
├── sonarlint.json
└── sonar-project.properties

Not only is the concept of making them replaceable or divisible in a Domain/Subdomain concept possible during the DDD process, but also in a directory/file way. For the purposes of this example, I’ve used a project in Node.js.

在DDD过程中，不仅可以在域/子域概念中使它们可替换或可分割，而且还可以目录/文件方式。 出于本示例的目的，我在Node.js中使用了一个项目。

Each operation of our Microservices had all the components that fulfilled the requirements of its development, config, Unit Testing, Performance Tests, Contract Test, scheme validations, and the Controller. So treating the operation as a whole allowed us to have control when our Microservices grow too much and have to be divided. So, we pretty much had to move the whole folder to its corresponding new Microservice. But that was it — no need to try to find the right components, or try to juggle them to make it work again.

微服务的每个操作都具有满足其开发，配置，单元测试，性能测试， 合同测试 ，方案验证和控制器要求的所有组件。 因此，将操作作为一个整体来对待，可以使我们在微服务增长过多而必须分开时能够控制。 因此，我们几乎不得不将整个文件夹移至其相应的新微服务。 就是这样-无需尝试找到正确的组件，也无需尝试使它们杂乱无章以使其再次正常工作。

NOTE: We generated the API route dynamically, so each operation is self descriptive enough, along with the package.json of the project, to build the route that we exposed. This allowed us the flexibility that we wanted: no more manual editing of the routes (lots of mistakes are often made here, so we wanted to avoid them). For example:

注意 ：我们动态生成了API路由，因此每个操作以及项目的package.json都具有足够的自我描述性，可以构建我们公开的路由。 这为我们提供了所需的灵活性：不再需要手动编辑路线(此处经常犯很多错误，因此我们希望避免这些错误)。 例如：

• VERB /{{Name of Artifact}}/{{Domain}}/{{Version}}/{{Subdomain}}/

  VERB / {{工件名称}} / {{Domain}} / {{Version}} / {{Subdomain}} /

  — N

  — N

  ame of Artifact: What kind of artifact are you exposing (Microservices, BFF, or any other)?

  神器的目的：您要暴露哪种神器(微服务， BFF或任何其他)？

  —

  -

  Domain: Self explanatory, the domain in which the operation belongs.

  域：自我说明，该操作所属的域。

  —

  -

  Version: Current major version that is available of our resource.

  版本：我们资源可用的当前主要版本。

  —

  -

  Subdomain: The operation that our Microservices will perform CRUD.

  子域：我们的微服务将执行CRUD的操作 。

• GET/Microservice/Client/v1/loan/ — GET all the loans that have been done by all the clients.
  GET / Microservice / Client / v1 / loan /-获取所有客户已完成的所有贷款。

It really sounds like magic, but I do highly recommend it. You’ll see that most of the problems you have when organizing your microservices will be reduced drastically.

听起来确实很神奇，但我强烈建议您这样做。 您会看到，组织微服务时遇到的大多数问题都将大大减少。

步骤5：文档 (Step 5: Documentation)

Uff, I have to say, I literally had chills. I can picture all of you agile practitioners, screaming your scrum souls out. But don’t you worry, I got you covered on this.

乌夫，我不得不说，我确实感到发冷。 我可以想象大家敏捷的实践者，尖叫您的scrum灵魂。 但是，您不用担心，我对此有所了解。

I’ll bring two concepts to play: first and most important, since we are exposing APIs, let’s all try this API First Development.

我将介绍两个概念：第一个也是最重要的，因为我们要公开API，所以我们都尝试一下API First Development。

API First Development is a strategy where the first order of business is to develop an Application Program Interface putting your target developer’s interest then build the product on top of it be it a website, mobile application or a SaaS software. By building on top of APIs with developers in mind, you and your developers are saving a lot of work while laying down the foundations for others to build on top of. (An API-First Development Approach by restcase).

API First Development是一种战略，其中首要任务是开发一个应用程序接口，使目标开发人员感兴趣，然后在该产品之上构建产品，无论是网站，移动应用程序还是SaaS软件。 通过考虑到开发人员在API之上进行构建，您和您的开发人员可以节省大量工作，同时也可以为其他人奠定基础。 (按大小写的API优先开发方法 )。

And how do we build this you may ask? Here is were our second concept come to play: Swagger, one of many tools to build APIs. This tool will open the gate to design and model APIs in a clean and organized way.

您可能会问我们如何构建它？ 这是我们要使用的第二个概念： Swagger ，许多构建API的工具之一。 该工具将打开以干净有序的方式设计和建模API的大门。

You can’t ask for anything better. Not only have we already solved the problem that we usually encounter in agility about documentation, but it also improves the way that the team will develop Microservices. It gives them the right tools to interact with each other, and removes the possibility that another team might say something like: “My team needed this as output, with these characteristics from this API, and we got nothing like that.” Then you can safely say: “This is the documentation of our API, designed and approved by the architect, fulfilling the requirements of the business”. Mic drop. So any further iteration would be around the well documented API.

你不能要求更好的东西。 我们不仅已经解决了我们通常在敏捷性方面遇到的关于文档的问题，而且还改善了团队开发微服务的方式。 它为他们提供了正确的工具来进行交互，并消除了另一个团队可能说出类似这样的可能性：“我的团队需要此作为输出，并具有此API的这些特征，而我们却一无所获。” 然后您可以放心地说：“这是我们的API的文档，由架构师设计和批准，可以满足业务需求”。 麦克风掉落。 因此，任何进一步的迭代都将围绕有据可查的API进行。

步骤6：训练 (Step 6: Training)

As I said early on, is up to us to make the best of our developers and teams. Take your time, identify the weaknesses and improve!

正如我早先所说的，我们有责任充分利用我们的开发人员和团队。 花点时间，找出缺点并加以改善！

I know that everyone has different preferences when training their teams, but I do highly recommend Coding Dojo when it comes down to agility and optimizing your team’s time. This training technique allowed us to train all of our teams so they had the same base level of expertise in each subject (Node.js, Microservices, Unit Testing, Performance tests, and more!). It also improved how the information was transmitted to the teams — we have all had play the game of telephone, and we know how it ends most of the time. No one has time to read years of documentation. We can even apply feedback from our teams to our daily lives. So everyone WINS!

我知道每个人在训练团队时都有不同的偏好，但是我强烈建议在敏捷性和优化团队时间方面使用Coding Dojo 。 这种培训技术使我们能够对所有团队进行培训，使他们在每个主题(Node.js，微服务，单元测试，性能测试等)上具有相同的基本专业知识。 这也改善了信息如何传递给团队-我们所有人都玩过电话游戏，而且我们知道信息在大多数情况下是如何结束的。 没有人有时间阅读多年的文档。 我们甚至可以将团队的反馈应用于我们的日常生活。 所以每个人都赢了！

经验教训和最后的话 (Lessons learned & final words)

For me it’s about knowing how all the pieces that are part of your ecosystem interact with one and other. It’s about learning how to react to them, because I can assure you that one day, you will think of a solution to a problem. But then you might end it up doing something completely different just to adapt to the requirements. That is the beauty of Microservices. They allow you to be flexible, and no matter how horrible it may look, if you follow the concept of replaceable pieces, loose coupling, and high cohesion, trust me, everything will be OK.

对我来说，这是关于了解生态系统中所有组成部分之间如何相互作用的信息。 这是关于学习如何对他们做出React，因为我可以向您保证，有一天，您会想到解决问题的方法。 但是，您可能最终会为了适应需求而做一些完全不同的事情。 那就是微服务的美。 它们使您变得灵活，无论看上去多么可怕，如果您遵循可更换部件，松散耦合和高内聚力的概念 ，请相信我，一切都会好的。

Microservice implementation is a journey for the brave that are willing to keep improving every single day. It’s for the ones who realize which things they could’ve done better, who see the big picture and make things right.

微服务的实施是勇敢者的旅程，他们愿意每天不断改进。 这是针对那些意识到自己可以做得更好的事情，看到全局并正确处理事情的人的。

As I said before, I wasn’t an expert when I started, and mistakes were made. But that didn’t stop me from doing things right. For all of you that out there struggling with your own Macroservices, mini-monoliths, microservice-hell, I can tell you this: Pause, take a deep breath, do your own diagnosis and improve. It’s not too late to do things right.

正如我之前所说，刚开始我不是专家，而且犯了错误。 但这并没有阻止我做正确的事。 对于所有人都在挣扎着自己的Macroservices，小型整体设备，微服务地狱的我，我可以告诉你：暂停，深呼吸，做自己的诊断并改善。 做正确的事情还为时不晚。

翻译自: https://www.freecodecamp.org/news/our-journey-into-the-world-of-microservices-and-what-we-learned-from-it-d255b9a2a654/

客户旅程