latest coding buzzword "microservices". Microservices, microservices, microservices. In this video

最新編碼熱詞 "微服務"。微服務，微服務，微服務。在這個視頻中

we'll go over what is a microservice, why people are moving to microservices, and finally

我們將介紹什麼是微服務，為什麼人們要轉向微服務，最後是

what you need to do to make an effective microservice.

你需要做什麼來製作一個有效的微服務。

So what is a microservice? Ask 20 developers what is a microservice, and you're likely

那麼什麼是微服務呢？問20個開發者什麼是微服務，你很可能會說

to get 25 different answers. Here's my best answer. A microservice is basically a self

得到25個不同的答案。這是我的最佳答案。一個微服務基本上是一個自

contained process that provides a unique business capability. Different microservices act in

包含的流程，提供獨特的業務能力。不同的微服務作用於

concert as one larger system, but behind the scenes, it's microservices all the way.

協同作為一個更大的系統，但在幕後，它是微服務的所有方式。

Take Amazon.com for instance. All we see is the website. Behind the scenes, Amazon has

以亞馬遜網站為例。我們看到的只是網站。在幕後，亞馬遜有

a service for accepting orders, a service for determining a list of recommended items

接受訂單的服務，確定推薦項目清單的服務。

to buy, a service to handle wish lists, a service for authenticating credit cards, and

購買、處理願望清單的服務、認證信用卡的服務，以及。

so on. All of these services are really mini applications performing a single business

諸如此類。所有這些服務其實都是執行單一業務的迷你應用。

capability.

能力。

What makes this organization interesting is, it is not organized around software layers.

這個組織的有趣之處在於，它不是圍繞軟件層來組織的。

We don't need to create a web microservice, business logic microservice or database microservice.

我們不需要創建一個Web微服務、業務邏輯微服務或數據庫微服務。

We are creating microservices around business capabilities. So we have a wish list microservice,

我們是圍繞業務能力來創建微服務。所以我們有一個願望清單微服務。

a order microservice, and a processing microservice.

一個訂單微服務，和一個處理微服務。

Microservices communicate with each other through a well-defined interface, usually

微服務之間通過一個定義良好的接口進行通信，通常為

REST or a messaging queue. The communication is almost always stateless.

REST或消息隊列。通信幾乎總是無狀態的。

The microservice data is federated as well. That means every microservice is responsible

微服務的數據也是聯合的。這意味著每個微服務都要負責

for its own data model and data. I think that statement just caused heart palpitations for

為自己的數據模型和數據。我想，這句話只是讓人心有餘悸，對於

some DBAs. There might be good business reasons to standardize the data platform for all microservices,

一些DBA。可能有很好的商業理由來標準化所有微服務的數據平臺。

but the idea is if we're on the team building the microservice, we should know best which

但我們的想法是，如果我們是構建微服務的團隊，我們應該最清楚哪一個

persistence model we need.

我們需要的持久性模型。

It's the latest buzzword, so why not? Seriously though, microservices make our system loosely

這是最新的流行語，為什麼不呢？不過說真的，微服務使得我們的系統鬆散地

coupled. If we need to upgrade, repair, or replace a microservice, we don't need to rebuild

耦合的。如果我們需要升級、修復或替換一個微服務，我們不需要重建

our entire application. Just swap out the part that needs it. Rebuilding isn't a big

我們的整個應用。只要把需要的部分換掉就可以了。重建不是一個大

deal for a small desktop app, but it can be a killer for a whole enterprise system.

對於一個小型的桌面應用來說，交易，但它可能是整個企業系統的殺手。

Breaking our system into small parts also allows each microservice to focus on a single

將我們的系統分解成一個個小的部分，也讓每個微服務都能專注於單一的

business capability. One benefit of this is we can have a small team focused on a simple

業務能力。這樣做的一個好處是我們可以讓一個小團隊專注於一個簡單的

task. Jeff Bezos from Amazon created the two pizza rule, the ideal size for a microservices

任務。來自亞馬遜的Jeff Bezos創造了兩個比薩餅規則，這是微服務的理想規模。

team is one you can feed with two pizzas.

團隊是一個你可以用兩個比薩餅來餵養。

Single benefit capabilities also help drive the focus of what our group is trying to accomplish.

單一的利益能力也有助於推動我們集團所要完成的重點工作。

It becomes very easy to determine if a feature is in or out if our goal is focused.

如果我們的目標集中，就很容易判斷一個功能是進還是退。

A simple interface means we can use different languages and tools. If we've got a great

簡單的界面意味著我們可以使用不同的語言和工具。如果我們有一個偉大的

well-defined interface, it doesn't matter what language or architecture we use. We could

定義良好的接口，我們使用什麼語言或架構並不重要。我們可以

write our service in Visual Basic if we wanted. As long as we publish how other services are

如果我們想的話，可以用Visual Basic寫我們的服務。只要我們發佈其他服務是如何

to communicate with our service, we're good to go. That's why the most common methods

與我們的服務溝通，我們就可以了。這就是為什麼最常見的方法

for communication between mircoservices are HTTP and messaging. Everybody supports that.

用於mircoservices之間通信的是HTTP和消息傳遞。大家都支持。

So what makes a great microservice? We've touched upon a few things already.

那麼是什麼造就了一個偉大的微服務呢？我們已經提到了幾件事。

First, I'll say it again. It focuses on a single business capability. That isn't to

首先，我再說一遍。它專注於單一的業務能力。這並不是說

say it does only one thing. Just one business thing. It does not mean we divide into a web

說它只做一件事。只做一件事。這並不意味著我們劃分到一個網

capability, logic capability, and database capability. That's going back to what we had

能力、邏輯能力和數據庫能力。這又回到了我們曾經的

before.

之前。

Each microservice should have it's own datastore. This limits what can change under the microservice.

每個微服務都應該有自己的數據存儲。這限制了微服務下可以改變的內容。

If another group is responsible for the data model, they can also change the data model.

如果另一個組負責數據模型，他們也可以改變數據模型。

That can force downstream changes for many microservice teams. Changes that might not

這可能會迫使許多微服務團隊進行下游變更。可能不會發生的變化

help our team at all.

幫助我們的團隊在所有。

Make communication stateless. If our communication is stateless, we can add more copies of the

讓通信成為無狀態。如果我們的通信是無狀態的，我們就可以增加更多的副本的

microservice at will. Stateless communication gives our microservice the ability to scale

微服務的隨意性。無狀態的通信讓我們的微服務有能力去擴展

effortlessly. Each interaction with our microservice can be handled by a different instance.

不費吹灰之力。與我們微服務的每個交互都可以由不同的實例來處理。

Since the communication is stateless, great microservices should be able to continue if

由於通信是無狀態的，偉大的微服務應該可以繼續，如果

another microservice fails. That means if we can't communicate with another service,

另一個微服務失敗。這意味著如果我們不能與另一個服務通信。

our service should be able to make due. If we're trying to get a list of suggested titles

我們的服務應該可以做到應有的效果。如果我們想得到一份建議的標題清單，我們的服務應該能夠滿足。

from another service, we'll have a default ready just incase. Our service should never

從另一個服務，我們會有一個默認的準備，以防萬一。我們的服務不應該

break, just because another service broke.

斷，只是因為另一個服務斷了。

Finally, a good team makes a good microservice. We need all parts represented. That's a designer,

最後，一個好的團隊才是一個好的微服務。我們需要所有的部分都有代表。這就是一個設計師。

web developer, coder, database admin, and operations all on our microservice team. Not

我們的微服務團隊中，web開發人員、編碼員、數據庫管理員、營運都有。不

representatives. On the team. It's everyone we need to make a fully functional application.

代表。在團隊中。是我們做一個功能齊全的應用所需要的每個人。

Up to two pizzas of course. And that doesn't mean find lots of developers who hate pizza.

當然最多隻能吃兩個披薩。而這並不意味著找到很多討厭披薩的開發者。

Hey! Thanks for watching the video. If you like what you're seeing or have any questions,

嘿！感謝你觀看視頻。如果你喜歡你所看到的或有任何問題，

let me know in the comments or on DeegeU.com! New videos come out each week, so make sure

請在評論中或在DeegeU.com上告訴我。每週都有新的視頻發佈，所以請務必要確保

you subscribe. You don't want to miss a video! In fact, lets go watch another DeegeU video.

您訂閱。你不想錯過任何一個視頻!事實上，讓我們去看另一個DeegeU視頻。

See you there!

到時見！