充分利用 cpu

Over the years, building and testing software that runs on physical servers has become the status quo. The database is the most important part of the application. Usually, it’s the only dependency an application has. Testing has become a no-brainer. Most of the tests are unit-tests and we run end-2-end tests manually or with Selenium to see if everything integrates properly.

多年來，構(gòu)建和測試在物理服務(wù)器上運(yùn)行的軟件已成為現(xiàn)狀。 數(shù)據(jù)庫是應(yīng)用程序中最重要的部分。 通常，它是應(yīng)用程序唯一的依賴項(xiàng)。 測試變得輕而易舉。 大多數(shù)測試是單元測試，我們手動(dòng)或使用Selenium運(yùn)行end-2-end測試，以查看是否一切集成正確。

Moving an application to the cloud is usually not too difficult. It will require some minor modifications. So why change anything to the way we build software?

將應(yīng)用程序遷移到云通常并不難。 它將需要一些小的修改。 那么，為什么要改變我們構(gòu)建軟件的方式呢？

1.)本地和云之間的區(qū)別 (1.) The difference between on-prem and cloud)

In the end, every application runs on a computer. The cloud, and on-premise both depend on physical servers in a datacenter. The difference is who owns them, who’s responsible for maintenance, and who pays for them.

最后，每個(gè)應(yīng)用程序都在計(jì)算機(jī)上運(yùn)行。 云和內(nèi)部部署均取決于數(shù)據(jù)中心中的物理服務(wù)器。 區(qū)別在于誰擁有它們，誰負(fù)責(zé)維護(hù)以及誰為它們付費(fèi)。

In the cloud, servers are shared amongst customers. On-premise, the company owns its hardware. On the bottom line that makes a difference:

在云中，服務(wù)器在客戶之間共享。 在內(nèi)部，公司擁有其硬件。 最重要的是：

定價(jià)模式 (The pricing model)

Buying a server is a one-time investment. It’s a matter of buying the hardware, some operating system licenses, and probably a database license. That should be sufficient to run some applications for a couple of years.

購買服務(wù)器是一次性的投資。 這是購買硬件，一些操作系統(tǒng)許可證甚至是數(shù)據(jù)庫許可證的問題。 這足以運(yùn)行一些應(yīng)用程序幾年。

To get the most out of the investment, the server will probably run as many applications as possible. And it will probably always be “up”. Shutting it down is probably more expensive than shutting it down. The only thing it needs is electricity, and that’s not expensive.

為了充分利用投資，服務(wù)器可能會(huì)運(yùn)行盡可能多的應(yīng)用程序。 而且它可能永遠(yuǎn)都是“向上”。 關(guān)閉它可能比關(guān)閉它更昂貴。 它唯一需要的是電力，而且價(jià)格并不昂貴。

Cloud is different. The biggest difference is: You can pay as you go. Rent a server for a day, delete it when you’re done. You’ll be charged for a single day of usage, not for one physical machine.

云是不同的。 最大的區(qū)別是：您可以隨用隨付。 租用服務(wù)器一天，完成后將其刪除。 您需要為一天的使用付費(fèi)，而不是為一臺(tái)物理計(jì)算機(jī)付費(fèi)。

服務(wù)器維護(hù) (Server maintenance)

To host a website on a server, for example. First, you’ll need a server with an operating system. Then, you’ll need to install and configure Apache or IIS. They require an operating system.

例如，將網(wǎng)站托管在服務(wù)器上。 首先，您需要一臺(tái)帶有操作系統(tǒng)的服務(wù)器。 然后，您需要安裝和配置Apache或IIS。 他們需要一個(gè)操作系統(tǒng)。

In the Cloud, you don’t need a server to get a website up. Just purchase the application-runtime instead. You’ll get a place where your application runs without having to purchase and configure a server, nor do you have to patch, or secure the operating system. That’s done by the cloud-vendor. That saves a lot of time, resources, and money.

在云中，您不需要服務(wù)器即可建立網(wǎng)站。 只需購買應(yīng)用程序運(yùn)行時(shí)即可。 您將獲得一個(gè)運(yùn)行應(yīng)用程序的地方，而無需購買和配置服務(wù)器，也不必修補(bǔ)或保護(hù)操作系統(tǒng)。 這是由云供應(yīng)商完成的。 這樣可以節(jié)省大量時(shí)間，資源和金錢。

Cloud doesn’t mean you can’t use Virtual Machines anymore. If you want, you can get one. But typically, they’re more expensive than using cloud-native components.

云并不意味著您不能再使用虛擬機(jī)。 如果需要，您可以選擇一個(gè)。 但是通常，它們比使用云原生組件要貴。

2.)充分利用云 (2.) Getting the best out of the cloud)

Moving to the cloud may be a matter of replacing the servers you have on-premise with virtual machines in the cloud. But a lift-and-shift approach has a down-side. It’s relatively expensive in the long run. Moving away from virtual machines to a more cloud-native approach creates opportunities and maybe cheaper.

遷移到云可能是用云中的虛擬機(jī)替換本地服務(wù)器的問題。 但是，升降換檔方式有一個(gè)缺點(diǎn)。 從長遠(yuǎn)來看，它相對昂貴。 從虛擬機(jī)轉(zhuǎn)向更具云原生的方法會(huì)帶來機(jī)會(huì)，而且價(jià)格可能更低。

Cloud-native applications aren’t just cheaper to host, they’re cheaper to build too. Using off-the-shelve components vastly shortens the time it takes to build an application and thus gives a business a competitive advantage.

原生云應(yīng)用程序不僅托管成本更低，而且構(gòu)建成本也更低。 使用現(xiàn)成的組件可以極大地縮短構(gòu)建應(yīng)用程序所需的時(shí)間，從而為企業(yè)帶來競爭優(yōu)勢。

使用云更快地構(gòu)建軟件 (Use the cloud to build software faster)

Nobody builds software from scratch anymore. Many generic parts of an application are available as an NPM- or a NuGet package. Cloud takes that to the next level:

沒人再從頭開始構(gòu)建軟件。 應(yīng)用程序的許多通用部分都可以作為NPM-或NuGet包使用。 云將其提升到一個(gè)新的水平：

• Software as a Service, the building blocks of a project

  軟件即服務(wù)，項(xiàng)目的基礎(chǔ)

  How many log-in screens have you built in your career? Finally, there’s no need to do so anymore. Such components are available as building blocks in the cloud. They provide user-management screens, MFA, and lots more. Auth0 and AD Connect offer this service for example. All you need to do is configure it, and wire it to your application.

  您的職業(yè)生涯中建立了多少個(gè)登錄屏幕？ 最后，不再需要這樣做。 這些組件可作為云中的構(gòu)建塊使用。 他們提供用戶管理屏幕，MFA等。 例如，Auth0和AD Connect提供此服務(wù)。 您所需要做的就是配置它，并將其連接到您的應(yīng)用程序。

  Lots of functionality is available in the cloud. Functionality like logging in, sending e-mails and text messages, facial/object recognition APIs, Blockchain, billing, support-ticketing, you name it. Combining these components with open-source packages makes it possible to build an application with very few lines of code.

  云中提供了許多功能。 您可以命名為登錄，發(fā)送電子郵件和文本消息，面部/對象識(shí)別API，區(qū)塊鏈，計(jì)費(fèi)，支持票證等功能。 將這些組件與開源軟件包結(jié)合在一起，就可以用很少的代碼行來構(gòu)建應(yīng)用程序。

• Infrastructure- and Platform as a Service and containers, the building blocks of the infrastructureSetting up a SQL server or an Active Directory server is history. All of that is available as a service in the cloud or a Docker container.

  基礎(chǔ)架構(gòu)和平臺(tái)即服務(wù)以及容器，基礎(chǔ)架構(gòu)的構(gòu)建塊設(shè)置SQL服務(wù)器或Active Directory服務(wù)器是歷史。 所有這些都可以在云或Docker容器中作為服務(wù)使用。

  Infrastructure- and Platform as a Service and containers, the building blocks of the infrastructureSetting up a SQL server or an Active Directory server is history. All of that is available as a service in the cloud or a Docker container.

  基礎(chǔ)架構(gòu)和平臺(tái)即服務(wù)以及容器，基礎(chǔ)架構(gòu)的構(gòu)建塊設(shè)置SQL服務(wù)器或Active Directory服務(wù)器是歷史。 所有這些都可以在云或Docker容器中作為服務(wù)使用。

  A lot of products are available as a service or have been containerized. There are two ways of getting SQL Server up and running, for example. Either pull a Docker image and run it or get a managed instance on Azure. This applies to a lot of different services. As a result, often, there’s no need to configure, maintain, and pay for a virtual server anymore.

  許多產(chǎn)品都可以作??為服務(wù)使用或已被包裝。 例如，有兩種啟動(dòng)和運(yùn)行SQL Server的方法。 提取Docker映像并運(yùn)行它或在Azure上獲取托管實(shí)例。 這適用于許多不同的服務(wù)。 因此，通常不再需要配置，維護(hù)和購買虛擬服務(wù)器。

For a lot of applications, either the cloud or open-source provides the building-blocks of an application. That changes the way an application is built. It requires fewer lines of code to build a working application. And compared to on-premise code, a lot more code will invoke third-party APIs or store state somewhere.

對于許多應(yīng)用程序，云或開源都提供了應(yīng)用程序的構(gòu)建塊。 這改變了應(yīng)用程序的構(gòu)建方式。 只需很少的代碼行即可構(gòu)建可運(yùn)行的應(yīng)用程序。 與本地代碼相比，更多代碼將調(diào)用第三方API或?qū)顟B(tài)存儲(chǔ)在某個(gè)地方。

Different services have different fees. In an early stage, it might be cheaper to store data in Azure Storage whereas when the amount of records increases, it might be more appealing to store (parts of) the data in a SQL Server instance. Applying patterns like Hexagonal/Ports-and-Adapters makes migrating easier.

不同的服務(wù)有不同的費(fèi)用。 在早期階段，將數(shù)據(jù)存儲(chǔ)在Azure存儲(chǔ)中可能會(huì)比較便宜，而當(dāng)記錄數(shù)量增加時(shí)，將數(shù)據(jù)(部分)存儲(chǔ)在SQL Server實(shí)例中可能會(huì)更有吸引力。 應(yīng)用六邊形/端口和適配器之類的樣式使遷移變得更加容易。

The down-sideThere’s a down-side, too. Your application has to be able to deal with services that are temporarily unavailable. Consuming SAAS products has an impact on the availability of the application. Most of the services have an uptime guarantee of 99.99%. But not every service will be down at the same moment. Imagine having an application that has a dependency on 3 services. The downtime is:

不利之處 也有不利之處。 您的應(yīng)用程序必須能夠處理暫時(shí)不可用的服務(wù)。 消費(fèi)SAAS產(chǎn)品會(huì)對應(yīng)用程序的可用性產(chǎn)生影響。 大多數(shù)服務(wù)的正常運(yùn)行時(shí)間保證為99.99％。 但是，并非所有服務(wù)都會(huì)在同一時(shí)間關(guān)閉。 想象有一個(gè)依賴于3個(gè)服務(wù)的應(yīng)用程序。 停機(jī)時(shí)間是：

99.99% * 99.99% * 99.99% = 99.97% uptime guarantee

99.99％* 99.99％* 99.99％= 99.97％的正常運(yùn)行時(shí)間保證

The more services are used, the lower the uptime guarantee gets. That’s why circuit breakers and Event-Driven Architecture is applied in cloud-native software.

使用的服務(wù)越多，正常運(yùn)行時(shí)間保證就越低。 這就是為什么將斷路器和事件驅(qū)動(dòng)架構(gòu)應(yīng)用于云原生軟件中的原因。

通過不支付閑置資源節(jié)省資金 (Save money by not paying for idle resources)

Imagine running a web-store. Usually, it has a couple of thousand visitors a day. On Black Friday, millions of customers visit the site. Hosting an application in the cloud could pay off in this scenario.

想象一下經(jīng)營一家網(wǎng)上商店。 通常，它每天有成千上萬的訪客。 在黑色星期五，數(shù)百萬的客戶訪問該網(wǎng)站。 在這種情況下，將應(yīng)用程序托管在云中可能會(huì)有所作為。

An on-premise configuration has a maximum capacity. The amount of hardware the business owns is probably an optimum between the cost of the hardware and the profit they will make with it. That might mean some potential customers are unable to visit the web-store on Black Friday because the server can’t handle the number of requests. It also means some of the servers the company owns have been purchased for the sole purpose of handling traffic on Black Friday. They’re idling for the rest of the year.

本地配置具有最大容量。 企業(yè)擁有的硬件數(shù)量可能是硬件成本與其將獲得的利潤之間的最佳選擇。 這可能意味著某些潛在客戶在黑色星期五無法訪問網(wǎng)上商店，因?yàn)榉?wù)器無法處理請求數(shù)量。 這也意味著已購買了公司擁有的某些服務(wù)器，其唯一目的是在黑色星期五處理流量。 他們在今年剩下的時(shí)間里都閑著。

In the cloud, it’s possible to scale up and down, vertically and horizontally whenever you want. As a result, it’s possible to scale up to the capacity needed to serve the site to every potential customer on Black Friday, and scaling down the next day. That way, the company can serve the site to every customer without having to pay for that capacity for the rest of the year.

在云中，您可以隨時(shí)隨地在垂直和水平方向上進(jìn)行縮放。 因此，可以在黑色星期五將規(guī)模擴(kuò)大到為每個(gè)潛在客戶提供站點(diǎn)服務(wù)所需的容量，并在第二天縮減規(guī)模。 這樣，公司可以為每個(gè)客戶提供站點(diǎn)服務(wù)，而無需在剩余的時(shí)間里為該容量付費(fèi)。

Horizontal scalingJust like on-premise, there’s a maximum to the vertical scale of a resource in the cloud. Under the bonnet, there’s always a physical server that has a limited number of CPUs.

水平擴(kuò)展與內(nèi)部部署一樣，云中資源的垂直擴(kuò)展最大。 在引擎蓋下，總是有一個(gè)物理服務(wù)器，其CPU數(shù)量有限。

The difference is in scaling horizontally. Cloud vendors have a vast amount of hardware available, allowing clients to scale horizontally, almost endlessly. An application doesn’t scale horizontally out of the box. It needs to be built in a certain way. How to, depends on the nature of an application, but commonly, APIs are made stateless, and read-, and write operations are separated with the CQ(R)S pattern. These patterns make it possible to use replica’s of the data sources for querying, decreasing the number of operations the main data source needs to process. To ensure every request can be processed, write-operations are queued.

區(qū)別在于水平縮放。 云供應(yīng)商擁有大量可用的硬件，允許客戶端幾乎無限地水平擴(kuò)展。 應(yīng)用程序無法橫向擴(kuò)展。 它需要以某種方式構(gòu)建。 如何使用取決于應(yīng)用程序的性質(zhì)，但通常使API成為無狀態(tài)的，并且使用CQ(R)S模式將讀寫操作分開。 這些模式使得可以使用數(shù)據(jù)源的副本進(jìn)行查詢，從而減少了主數(shù)據(jù)源需要處理的操作數(shù)量。 為了確保可以處理每個(gè)請求，將寫操作排隊(duì)。

Relational databases don’t scale well. Consider using a NoSQL database instead.

關(guān)系數(shù)據(jù)庫無法很好地?cái)U(kuò)展。 考慮改用NoSQL數(shù)據(jù)庫。

通過最小化部署的影響來改善用戶體驗(yàn) (Improve user experience by minimizing the impact of deployments)

Imagine running an international webshop. Typically, when you’re deploying a new version, it’s a good practice to take the current version offline when the newer version is up and running. But how do you know it’s up? Is it up when a given endpoint returns a 200 OK? Or is it up if customers keep ordering products on the webshop?

想象一下，經(jīng)營一家國際網(wǎng)上商店。 通常，在部署新版本時(shí)，最好的做法是在新版本啟動(dòng)并運(yùn)行時(shí)使當(dāng)前版本脫機(jī)。 但是你怎么知道它上升了呢？ 給定的端點(diǎn)返回200 OK時(shí)是否正常？ 還是客戶繼續(xù)在網(wǎng)上商店訂購產(chǎn)品呢？

Being able to run multiple versions of the same software makes it possible to serve the newer version of the software to a small number of end-users. Undo the deployment automatically if the newer version causes issues that haven’t been identified during the testing process. Monitoring the conversion-points on the website makes will tell if the newer version of the software is still functioning correctly. In the example of the webshop, an indicator could be: Are people still ordering products? If they aren’t, roll back the deployment!

能夠運(yùn)行同一軟件的多個(gè)版本使向少數(shù)最終用戶提供該軟件的較新版本成為可能。 如果較新版本導(dǎo)致測試過程中未發(fā)現(xiàn)問題，則自動(dòng)撤消部署。 監(jiān)視網(wǎng)站上的轉(zhuǎn)換點(diǎn)將告知該軟件的較新版本是否仍在正常運(yùn)行。 在網(wǎng)上商店的示例中，指標(biāo)可能是：人們是否還在訂購產(chǎn)品？ 如果不是，請回滾部署！

These concepts (blue-green, ring-based, and canary releasing) have been around for some time. They aren’t cloud-specific concepts, but they’re easy to apply in the cloud and they minimize the impact of deployments. As a result, potential issues have a much smaller impact on the business.

這些概念(藍(lán)綠色，基于環(huán)的和金絲雀釋放)已經(jīng)存在了一段時(shí)間。 它們不是特定于云的概念，但是它們很容易在云中應(yīng)用，并且可以最大程度地減少部署的影響。 因此，潛在問題對業(yè)務(wù)的影響要小得多。

3.)它如何影響軟件和測試 (3.) How it impacts the software and the tests)

To build an application faster, to deploy it smarter, and to scale it more efficiently, the software can’t be built the same way on-premise oriented applications are built. To get the most out of the cloud, it needs to have the following characteristics:

為了更快地構(gòu)建應(yīng)用程序，更智能地部署應(yīng)用程序并更有效地進(jìn)行擴(kuò)展，不能以與構(gòu)建面向內(nèi)部的應(yīng)用程序相同的方式來構(gòu)建軟件。 為了充分利用云，它需要具有以下特征：

• It needs to be backward compatible, to support running different versions simultaneously.
  它需要向后兼容，以支持同時(shí)運(yùn)行不同版本。
• Read- and write operations need to be separated to support horizontal scaling.
  讀寫操作需要分開以支持水平縮放。
• APIs need to be stateless to support horizontal scaling.
  API必須是無狀態(tài)的，以支持水平縮放。
• The application needs to cope with the fact that parts of the infrastructure may be temporarily unavailable.
  該應(yīng)用程序需要處理部分基礎(chǔ)架構(gòu)可能暫時(shí)不可用的事實(shí)。
• The tests need to be quick enough to support deploying multiple versions of the software a day
  測試必須足夠快以支持每天部署多個(gè)版本的軟件

常見模式 (Common patterns)

On-premise, when a server is down, every application on the server is down. With cloud-native applications, that’s not the case anymore. Probably, only a little part of the infrastructure will be down. When the application is built right, just a little part of it is impacted. And by having multiple small applications, instead of one giant application, the impact of an outage may even smaller.

在本地，當(dāng)服務(wù)器關(guān)閉時(shí)，服務(wù)器上的每個(gè)應(yīng)用程序都關(guān)閉。 對于云原生應(yīng)用程序，情況已不再如此。 可能只有一小部分基礎(chǔ)架構(gòu)將崩潰。 正確構(gòu)建應(yīng)用程序后，只會(huì)影響一小部分。 而且通過擁有多個(gè)小型應(yīng)用程序(而不是一個(gè)大型應(yīng)用程序)，中斷的影響可能會(huì)更小。

Assume we’re still running a webshop and there’s a database outage. Normally, it would be impossible for a customer to complete his order in that case. It can’t be stored in the database. Event-Driven Architecture makes the application more robust. Event-Driven applications treat the event of a customer completing his order is an “event”, which is stored in a queue. If the database is down, the event can’t be processed and will be saved so it can be retried later.

假設(shè)我們?nèi)栽谶\(yùn)行網(wǎng)上商店，并且數(shù)據(jù)庫中斷。 通常，在這種情況下，客戶將無法完成其訂單。 無法將其存儲(chǔ)在數(shù)據(jù)庫中。 事件驅(qū)動(dòng)的體系結(jié)構(gòu)使應(yīng)用程序更強(qiáng)大。 事件驅(qū)動(dòng)的應(yīng)用程序?qū)⒖蛻敉瓿善溆唵蔚氖录暈椤笆录?#xff0c;存儲(chǔ)在隊(duì)列中。 如果數(shù)據(jù)庫關(guān)閉，則無法處理該事件并將其保存，以便以后可以重試。

There are several ways to build an Event-Driven application. Commonly, Command Query Responsibility Segregation is applied, meaning one part of the application is responsible for processing all write operations, and another is responsible for handling all read operations. The read operations use a separate, dedicated read-model; a queryable representation of the main data source of the application.

有幾種方法可以構(gòu)建事件驅(qū)動(dòng)的應(yīng)用程序。 通常，應(yīng)用命令查詢責(zé)任隔離 ，這意味著應(yīng)用程序的一部分負(fù)責(zé)處理所有寫入操作，而另一部分負(fù)責(zé)處理所有讀取操作。 讀取操作使用單獨(dú)的專用讀取模型。 應(yīng)用程序主數(shù)據(jù)源的可查詢表示形式。

The write-part of CQRS works with events, event-handlers, commands, and command-handlers. By increasing the number of nodes that process these commands and events, by introducing replicas of the read-model, and by increasing the number of nodes that process the read operations, the application scales horizontally, endlessly.

CQRS的寫部分可用于事件，事件處理程序，命令和命令處理程序。 通過增加處理這些命令和事件的節(jié)點(diǎn)的數(shù)量，通過引入讀取模型的副本，以及通過增加處理讀取操作的節(jié)點(diǎn)的數(shù)量，應(yīng)用程序可以無限地水平擴(kuò)展。

The tricky part is to model the commands and events correctly. Often, people use Domain-Driven Design to create the model.

棘手的部分是正確建模命令和事件。 人們經(jīng)常使用域驅(qū)動(dòng)設(shè)計(jì)來創(chuàng)建模型。

持續(xù)交付？ 逐步交貨！ (Continuous Delivery? Progressive delivery!)

Backward compatibility doesn’t have that big an impact on the software itself. It impacts the software delivery process. The database is usually the dependency that needs to be backward compatible. Removing a column isn’t a matter of just dropping it anymore. When two different versions are used simultaneously, they write data to the same data source differently. The software needs to cope with that. As a result, it takes quite some releases to change a data-schema.

向后兼容性對軟件本身沒有太大影響。 它影響軟件交付過程。 數(shù)據(jù)庫通常是需要向后兼容的依賴項(xiàng)。 刪除列不再只是刪除它的問題。 當(dāng)同時(shí)使用兩個(gè)不同的版本時(shí)，它們以不同的方式將數(shù)據(jù)寫入同一數(shù)據(jù)源。 該軟件需要解決。 結(jié)果，要花費(fèi)大量的時(shí)間來更改數(shù)據(jù)架構(gòu)。

To change a database in a backward-compatible way, use a method called Expand and Contract or Parallel Change and approach releasing the software differently.

要以向后兼容的方式更改數(shù)據(jù)庫，請使用稱為擴(kuò)展和收縮或并行更改的方法 并以不同方式發(fā)布軟件。

Typically, a release contains one or more features. With Expand and Contract, it takes five releases to change a database-schema. As a result, it takes at least five releases to create a new feature. In other words:

通常，發(fā)行版包含一個(gè)或多個(gè)功能。 使用Expand and Contract，需要五個(gè)發(fā)行版來更改數(shù)據(jù)庫架構(gòu)。 結(jié)果，至少需要五個(gè)版本才能創(chuàng)建新功能。 換一種說法：

Release != feature

發(fā)布！=功能

Having backward-compatible versions of the software makes it possible to do:

具有該軟件的向后兼容版本可以實(shí)現(xiàn)以下目的：

• Canary releasing

  金絲雀釋放

  Bring a new version to production and introduce it to a small group before deploying it to all of the end-users. Get real user feedback and be sure the new release doesn’t cause trouble.

  將新版本投入生產(chǎn)并將其介紹給一個(gè)小組，然后再將其部署到所有最終用戶。 獲得真實(shí)的用戶反饋，并確保新版本不會(huì)造成麻煩。

• Blue-green deployments

  藍(lán)綠色部署

  Deploy new versions of the software anytime a day without causing downtime.

  每天隨時(shí)部署新版本的軟件，而不會(huì)造成停機(jī)。

• Dark-launching

  暗發(fā)射

  Ship new functionality to a small group of end-user and get real user feedback.

  向少數(shù)最終用戶提供新功能，并獲得真實(shí)的用戶反饋。

測試中 (Testing)

In many cases, an end-2-end-test requires a system to be in a given state. To get it in that state, usually, database scripts populate the database with test data.

在許多情況下，最終2項(xiàng)最終測試要求系統(tǒng)處于給定狀態(tài)。 為了使它處于這種狀態(tài)，通常，數(shù)據(jù)庫腳本會(huì)用測試數(shù)據(jù)填充數(shù)據(jù)庫。

Having multiple, smaller applications, which all have their own (type of) data-source, makes end-2-end testing very complicated. Every individual microservice needs to be set-up differently.

擁有多個(gè)較小的應(yīng)用程序，每個(gè)應(yīng)用程序都有自己的(數(shù)據(jù)類型)數(shù)據(jù)源，這使得端到端的測試非常復(fù)雜。 每個(gè)單獨(dú)的微服務(wù)都需要進(jìn)行不同的設(shè)置。

And cutting big application into small ones, and deploying it frequently introduces a problem: Versions… Every environment will have different versions of the software all the time. And if it has the correct version today, it’s will be replaced with a newer one tomorrow.

將大型應(yīng)用程序分解為較小的應(yīng)用程序并進(jìn)行部署經(jīng)常會(huì)帶來一個(gè)問題：版本…每個(gè)環(huán)境始終會(huì)具有不同的軟件版本。 如果今天的版本正確，則明天將替換為較新的版本。

To cope with that, the test suite needs to have the following characteristics:

為了解決這個(gè)問題，測試套件需要具有以下特征：

• Daily releases are impossible if the testing process takes longer than a day. The faster the test-suite, the better. The test-suite needs to be able to run in less than half a day.
  如果測試過程需要一天以上的時(shí)間，則不可能每天發(fā)布。 測試套件越快越好。 測試套件需要能夠在不到半天的時(shí)間內(nèi)運(yùn)行。
• Maintenance of the test cannot take longer than half a day.
  測試的維持時(shí)間不能超過半天。
• They can guarantee working software, end to end, in every environment (even in production)
  他們可以保證在每個(gè)環(huán)境(甚至在生產(chǎn)環(huán)境)中都能端到端運(yùn)行軟件

Maintenance to an end-2-end test makes changing the software fast, and frequently they’re too complex. There’s a new alternative: Contract testing. As a result, every individual application gets its testing pyramid which looks like this:

維護(hù)端到端2個(gè)測試可以快速更改軟件，而且它們過于復(fù)雜。 有一個(gè)新的替代方法： 合同測試 。 結(jié)果，每個(gè)單獨(dú)的應(yīng)用程序都會(huì)獲得其測試金字塔，如下所示：

Being able to run different versions of the software opens another door. Testing changes into a process you do in production, too. By being able to run different versions of the same software it’s now possible to:

能夠運(yùn)行不同版本的軟件打開了另一扇門。 也測試變更到您在生產(chǎn)中所做的過程。 通過能夠運(yùn)行同一軟件的不同版本，現(xiàn)在可以：

• Do dark launches
  做暗發(fā)射
• Do A/B testing
  做A / B測試
• Ring based deployments
  基于環(huán)的部署
• Canary releasing
  金絲雀釋放
• And so forth…
  依此類推...

摘要 (Summary)

Cloud is more than server virtualization. In fact, for many applications, there’s no need to have a server at all. Cloud vendors offer infrastructure as a service. All you need to do is select the components the application needs, and the cloud vendor supplies it. It’s a lot cheaper, too.

云不僅僅是服務(wù)器虛擬化。 實(shí)際上，對于許多應(yīng)用程序，根本不需要服務(wù)器。 云供應(yīng)商提供基礎(chǔ)架構(gòu)即服務(wù)。 您需要做的就是選擇應(yīng)用程序所需的組件，然后由云供應(yīng)商提供。 也便宜很多。

Because you’re not owning any hardware, when you’re in the cloud, it’s possible to scale up, and down, whenever need be. That way, you can always get the capacity you need at a particular moment.

由于您沒有任何硬件，因此當(dāng)您在云中時(shí)，可以在需要時(shí)進(jìn)行向上和向下擴(kuò)展。 這樣，您始終可以在特定時(shí)刻獲得所需的容量。

The cloud offers software as a service, too. Building your own log-in screen may be a thing of the past. Selecting the components you need to build your application, makes building the software a lot simpler.

云也提供軟件即服務(wù)。 建立自己的登錄屏幕可能已成為過去。 選擇構(gòu)建應(yīng)用程序所需的組件，使軟件的構(gòu)建變得更加簡單。

Build applications differently to exploit the possibilities of the cloud.

以不同的方式構(gòu)建應(yīng)用程序以利用云的可能性。

• Use Event-Driven Architecture and CQRS to be able to scale horizontally
  使用事件驅(qū)動(dòng)架構(gòu)和CQRS可以水平縮放
• Apply Domain-Driven Design to cut your monolith into little pieces
  應(yīng)用域驅(qū)動(dòng)設(shè)計(jì)將整塊切割成小塊
• Stop releasing when a feature is done, release all the time
  完成功能后停止發(fā)布，一直發(fā)布
• Do not use E2E testing, use Contract Testing instead
  不要使用E2E測試，而是使用合同測試

接下來做什么 (What to do next)

Applying Domain-Driven Design, CQRS and the testing pyarmid is complex. Read how to, and find example code in the following articles:

應(yīng)用域驅(qū)動(dòng)設(shè)計(jì)，CQRS和測試pyarmid非常復(fù)雜。 閱讀方法，并在以下文章中找到示例代碼：

翻譯自: https://medium.com/vx-company/how-to-get-the-most-out-of-the-cloud-eb1b8b2826fe

充分利用 cpu

總結(jié)

以上是生活随笔為你收集整理的充分利用 cpu_如何充分利用云的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。