客戶旅程

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，小型整體設備，微服務地獄的我，我可以告訴你：暫停，深呼吸，做自己的診斷并改善。做正確的事情還為時不晚。