nsa组网语音部署策略_部署策略

最新推荐文章于 2024-03-20 15:51:28 发布

weixin_26704853

最新推荐文章于 2024-03-20 15:51:28 发布

阅读量802

点赞数

文章标签： java docker leetcode 人工智能 python

原文链接：https://towardsdatascience.com/deployment-strategies-a4fe6f743e08

版权

nsa组网语音部署策略

There is a point when every application will be deployed. We can delegate this activity to an automated task or do it manually, but we need to have a deploy strategy behind the scenes. I read many guides about deployments, most of them where good explanations about how you can implement a given solution. The missing link with the real world is matching the implementation with the needs. In simple words, you must understand your requirement before applying a solution. That’s why I want to focus on the scenarios as well as the strategies.

有一点将部署每个应用程序。我们可以将此活动委派给自动化任务或手动完成，但是我们需要在幕后制定部署策略。我阅读了许多有关部署的指南，其中大多数指南都很好地解释了如何实施给定的解决方案。与现实世界的缺失环节使实施与需求相匹配。简而言之，在应用解决方案之前，您必须了解您的要求。这就是为什么我要专注于场景和策略。

为什么我们需要权衡 (Why we need a trade-off)

You will discover in the next paragraph that each deployment strategy satisfies different needs. Recognize your use-case is essential for selecting the right tool. Each solution must be compatible with the application requirements, and this also includes the budget variable into the list.

在下一段中，您将发现每种部署策略都可以满足不同的需求。认识到用例对于选择正确的工具至关重要。每个解决方案都必须与应用程序要求兼容，并且还将预算变量包括在列表中。

You are right; it scents of trade-off threat. But that’s what it is. You cannot shoot a fly with a bazooka.

你是对的; 权衡威胁的气味。但这就是事实。你不能用火箭筒射击苍蝇。

Ask your customer if he prefers a deployment strategy that doesn’t bring offline its service or not. I think it’s easy to guess its answer.

询问您的客户是否喜欢不使服务脱机的部署策略。我认为很容易猜出答案。

When it is possible, we need to keep the service alive during the deployment process. For a simple application, with few users, this may seem overkill, but it’s often possible to implement a zero-downtime DevOps process with the same effort. So, probably, the zero-downtime is something we should always put into account.

在可能的情况下，我们需要在部署过程中使服务保持活动状态。对于一个用户很少的简单应用程序，这似乎有些过头了，但是通常可以以相同的努力实现零停机DevOps流程。因此，零停机时间可能是我们应该始终考虑的问题。

In many scenarios, we need to maintain two versions at the same time (old and new, with and without the new feature,etc.). This solution is relatively easy to implement if you think of your automated deployment services, maybe with an infrastructure creation stage. The significant matter is the cost. Not often, running two instances of the same application is link running two simple virtual machines. For a vast system, the cost of doubling the infrastructure to run two parallel versions of an application may be prohibitive. So, probably, keeping multiple systems available at the same time will be an issue.

在许多情况下，我们需要同时维护两个版本(旧版本和新版本，带有和不带有新功能，等等)。如果考虑到自动化部署服务，则可能在基础架构创建阶段，该解决方案相对容易实现。重要的是成本。运行同一应用程序的两个实例并不经常是运行两个简单虚拟机的链接。对于庞大的系统，将基础架构加倍以运行应用程序的两个并行版本的成本可能会高得让人望而却步。因此，可能需要同时保持多个系统可用。

I can continue with other examples, but the question is simple. We need to tune our solution on the real need of the application.

我可以继续其他示例，但是问题很简单。我们需要根据应用程序的实际需求调整解决方案。

Simplifying too much leads to something that works today, but will stop working tomorrow. Being too much far-sighted let you sleep soundly but may impact on your budget.

简化太多会导致今天起作用，但明天就会停止起作用。远见卓识会让您安然入睡，但可能会影响您的预算。

部署策略 (Deployment strategies)

重新建立 (Recreate)

The old version is shut down; then, the new one is activated. This process is what happens when you have a simple server, and you update your web site.

旧版本已关闭；然后，新的被激活。当您拥有简单的服务器并更新网站时，将发生此过程。

Pros:

优点：

Easy to implement
易于实施

Cons:

缺点：

A small downtime is required.
需要少量的停机时间。
In case of some error, the switch is hard.
如果出现某些错误，切换会很困难。

倾斜 (Ramped)

The new version is deployed and progressively delivered to the users. This solution is suggested when you are releasing a new application, and you want to tune the performance or some critical feature. It’s also a good option if you’re going to collect users’ feedback and adjust your application before the big launch.

新版本已部署并逐步交付给用户。当您发布新应用程序并且想要调整性能或某些关键功能时，建议使用此解决方案。如果您要在发布之前收集用户的反馈并调整应用程序，这也是一个不错的选择。

Pros:

优点：

progressive
进步

Cons:

缺点：

long time to reach the full deployment
需要很长时间才能完成全面部署
expensive (in case you apply this solution for existing applications you will have two running environments)
昂贵(如果您将此解决方案应用于现有应用程序，则将有两个运行环境)

蓝绿 (Blue\Green)

The new version is deployed alongside the other one; then, the traffic is switched to the new server. The switch happens only when the new version is online and tested, so the operation is immediate and safe.

新版本与另一个版本同时部署。然后，流量将切换到新服务器。仅当新版本在线且经过测试时，才进行切换，因此操作是立即且安全的。

Pros:

优点：

Safe
安全
No downtime
无停机时间

Cons:

缺点：

Hard to implement
难以实施
Require two running environments for a while (expensive)
需要两个运行环境一段时间(昂贵)
Many web servers implement a Blue\Green mechanism internally so that you can get the same out of the box.
许多Web服务器在内部实现了Blue \ Green机制，因此您可以立即使用它们。

A / B测试 (A/B Testing)

Both versions, new and old, work together. Some targeted users land on the new one so that you can get feedback

新旧版本都可以一起使用。一些有针对性的用户登陆了新用户，以便您获得反馈

Pros:

优点：

you can compare both platforms and get feedback
您可以比较两个平台并获得反馈

Cons:

缺点：

expensive
昂贵
hard to implement on a full application, because you need two running application on the same database
很难在完整的应用程序上实施，因为您需要在同一数据库上运行两个应用程序

阴影 (Shadow)

The new version of the application receives traffic through the old platform and gives a retro compatible response to the caller.

新版本的应用程序通过旧平台接收流量，并向调用者提供回溯兼容的响应。

Pros:

优点：

Ensure retro compatibility
确保复古兼容性
Transparent for the user
对用户透明

Cons:

缺点：

Hard to implement on a full web application
难以在完整的Web应用程序上实现
Give you the restrictions to be compliant with the old application forever.
为您提供限制，使其永远与旧应用程序兼容。

选择正确的策略。 (Choose the right strategy.)

Well, it depends on needs and budget. This first sentence is impeccable but fully useless 😅. So, I will try to map the right solution for each condition so that you could pick the right one.

好吧，这取决于需求和预算。第一句话是无可挑剔的，但完全没用。因此，我将尝试为每种情况映射正确的解决方案，以便您可以选择正确的解决方案。

新的应用程序投放市场 (New application land to the market)

When a new application comes to production, there isn’t anything to broke, so it is all easier. Until the go-live, you can activate a new application using a recreate or Green/Blue approach. The only regret about this proposal is that you will have a complete switch. All users will enter your web application together, during the launch day. This is not a problem in an ideal world where there isn’t any bug, analysis leak, or performance issue. In the real world, a turn-key is always a bet, even if you have done the best analysis possible, you tested everything twice, and run a performance test. My suggestion is to have a ramped deployment when possible. Starting with a limited number of user let you collect feedback and solve the problem without emergencies.

当一个新的应用程序投入生产时，没有什么坏的，所以一切都变得容易。在上线之前，您可以使用重新创建或Green / Blue方法激活新的应用程序。对此建议唯一的遗憾是您将有一个完整的选择。在发布之日，所有用户将一起进入您的Web应用程序。在没有错误，分析漏洞或性能问题的理想世界中，这不是问题。在现实世界中，交钥匙始终是一个赌注，即使您已进行了尽可能最好的分析，也对所有内容进行了两次测试，并进行了性能测试。 我的建议是在可能的情况下扩大部署。 从数量有限的用户入手，您可以收集反馈并解决问题而不会出现紧急情况。

现有应用程序的更新 (An update of an existing application)

When an application is live, I feel hard to deploy a new version progressively or do an A/B test at the application level. The big issue is about the fact that you would need two different applications running, with doubled expenses, and both applications will have to share the same database. But there is also a practical constraint. Who knows about the user? Who decides which customer is eligible for the A or B version? The answer is easy: Business logic. So, the easier place to manage this is inside the application, where the business logic resides. To solve the need of balance across different features, the easier solution is to operate at the application level. You can simply deploy an application with two features that can be activated by the user. In the microservice age, it is relatively easy to add or remove parts and use applying some business logic. Why not?

当一个应用程序处于活动状态时，我很难逐步部署新版本或在应用程序级别进行A / B测试。最大的问题是您需要运行两个不同的应用程序，而费用却增加了一倍，并且两个应用程序必须共享同一数据库。但是也有一个实际的限制。谁知道用户？谁决定哪个客户有资格使用A或B版本？答案很简单：业务逻辑。因此，更容易管理此位置的地方是业务逻辑所在的应用程序内部。为了解决不同功能之间的平衡需求，更简单的解决方案是在应用程序级别进行操作。您可以简单地部署具有两个可由用户激活的功能的应用程序。在微服务时代，添加或删除部件以及应用一些业务逻辑相对容易。为什么不？

Once you can manage the A/B test or ramped activation of new features inside the application, you will need a deployment that doesn’t break anything. A Blue/Green deployment will be ok.

一旦您可以管理A / B测试或应用程序中新功能的逐步激活，您将需要一个不会破坏任何内容的部署。可以进行蓝色/绿色部署。

您要替换旧版Web服务。 (You want to replace a legacy web service.)

When you have a legacy API used from thousand of users, replacing it is always a mess. Issues may be from users that used the IP address instead of DNS, or firewall issues. Any small change may cause problems, so we want to be super conservative. The Shadow release deployment is the right solution. Mocking all the responses, the caller can continue to make the same as usual, while you started the new system. Then you can ask the user to switch and monitor the old API usage but without a hurry. In the end, you can close the old interface without any fear of cutting away some users. The big issue is the cost of maintaining two different systems and keep them aligned, almost in the interface with the user (if you change something on the real service, the mock need to remain compliant with the initial definition). Moreover, the fact that you will have to support the old API interface on the mock interface may limit your capabilities in some way.

当您有成千上万的用户使用旧版API时，替换它总是很麻烦。问题可能出在使用IP地址而不是DNS的用户，或者是防火墙问题。任何微小的变化都可能导致问题，因此我们要超级保守。 Shadow版本的部署是正确的解决方案。模拟所有响应后，在您启动新系统时，呼叫者可以继续像往常一样进行操作。然后，您可以要求用户切换和监视旧的API使用情况，而不必着急。最后，您可以关闭旧界面，而不必担心会砍掉一些用户。最大的问题是维护两个不同系统并使它们几乎在与用户的界面中保持一致的成本(如果您更改了真实服务上的某些内容，则模拟需要保持与初始定义的一致性)。此外，您必须在模拟接口上支持旧的API接口这一事实可能会在某种程度上限制您的功能。

您要向现有产品添加新功能。 (You want to add a new feature to an existing product.)

When you are adding a feature on an existing project, and you want to test correctly before the full enrollment, an A/B or ramped deployment can be useful. The first one lets you compare the effect of the two applications on the users, but the second one gradually introduces a new feature. Both ways are an interesting and useful approach to improve user engagement but are hard to implement for each feature. The main problem is to keep two concurrent versions of the application running together. This means double infrastructural cost, double maintenance cost, need to keep database compatible with two running applications. For all of these problems, in most cases, you can manage a gradual deployment at the application level. This approach also has the advantages that you can define a custom policy per user very easily inside the user scope.

当您在现有项目中添加功能时，并且想要在完全注册之前进行正确测试时，A / B或渐变部署可能会有用。第一个可以让您比较这两个应用程序对用户的影响，但是第二个可以逐步引入新功能。两种方式都是提高用户参与度的有趣且有用的方法，但是很难为每个功能实现。主要问题是使两个并发版本的应用程序一起运行。这意味着基础设施成本翻倍，维护成本翻倍，需要使数据库与两个正在运行的应用程序兼容。对于所有这些问题，在大多数情况下，您可以在应用程序级别管理逐步部署。这种方法的优势还在于，您可以在用户范围内轻松地为每个用户定义自定义策略。

带什么回家 (What to take home)

Deploying an application is a tricky aspect of DevOps and must respect some business requirement for being effective. There are many options, as usual. Many of them work, but you can pick the most suitable for you.

部署应用程序是DevOps的棘手方面，必须遵守一些业务要求才能有效。和往常一样，有很多选择。他们中的许多人都能工作，但是您可以选择最适合自己的人。