用微服务器替代整体应用程序，或者建立新的应用程序，是开发团队日益增长的考虑因素，这些开发团队希望提高敏捷性，迭代速度更快，并跟上市场变化。通过在不同团队之间提供更大的自主权，允许他们并行工作，在更短的时间内实现更多的功能，微服务器提供的代码不那么脆弱，从而更容易进行更改，测试和更新。

Docker容器适合微服务，因为它们具有自主性，自动化和便携性。具体来说，Docker以其封装特定应用程序组件及其所有依赖关系的能力而闻名，从而使团队能够独立工作，而无需底层基础架构或底层基础来支持其正在使用的每一个组件。

此外，Docker使得创建轻量级的隔离容器非常容易，它们可以轻巧。因为应用程序与底层架构解耦，因此它十分轻便并易于使用。而且很容易创建一套新的容器;Docker编排解决方案(如Docker Swarm，Kubernetes或AWS ECS)可轻松地加速由多个容器组成的新服务，并全部以全自动的方式进行。因此，Docker非常适合微服务。

在构建基于Docker的微服务解决方案时，有几个过程和技术设计要考虑。以下10个考虑，有助于开发团队少走弯路。

流程考虑：

1.现有的微服务将如何更新?

开发人员使用微服务的根本原因是加快开发速度，从而增加对微服务进行更新的频次。要充分利用微服务，这个过程是至关重要的。

但是，有几个组成部分组成这个过程，并且在进程的每一步都有决定。让我们借助三个例子来解释一下。首先，是否设置连续部署或设置人员按下仪表板的按钮来部署新版本。权衡是更高的灵活性，持续部署，或采用手动触发部署的更严格的管理。自动化可以允许以敏捷性实现安全性，并允许共同存在的好处。开发人员需要决定他们的工作流程，以及他们需要什么自动化，以及在哪里部署。

第二，企业要考虑实际容器建设的重要性。它会在基于本地建立，推送和通过管道吗?或者将实际代码首先转换成产品，然后转换为一直到生产的Docker镜像?如果使用容器在管道中建造的解决方案，重要的是要考虑将要建立的位置，以及要使用的工具。

第三，要考虑实际部署策略。具体来说，可以通过蓝绿色的部署设置来更新微服务体系结构，其中一组新的容器被分离出来，然后删除旧的容器。或者，可以选择滚动更新，当通过多个服务容器，创建一个新的容器，并将其投入使用。这些决定是多方面的，需要考虑几个因素，包括当前流量，运营商的技能水平以及技术方向。

2.开发商如何开始全新的服务?

开展新服务是微服务的基本要求。因此，开展全新服务的过程应尽可能简单。在这方面，一个重要的问题是，“如何让开发人员以自助服务方式启动新服务，而不会影响安全性和治理?”它需要通过审批流程，如提交IT请求?或者，这将是一个完全自动化的过程?

尽管我建议使用尽可能多的自动化，但这绝对是开发团队想要提前思考的点，以确保他们正确平衡安全性，治理和自助服务的需求。

3.服务如何分配URL?

这个问题真的与开创全新的服务紧密相连。需要在每次创建新的URL或子上网(例如myurl.com/myservice)时将其分配给新服务，并且分配它们的过程应该理想地自动化。选项可以包括一个用于手动分配URL的自助服务门户或一个进程，其中URL被自动分配并从Docker容器的名称和应用于Docker容器的任何标签中提取。

再次，就像启动一项新服务一样，我建议在尽可能多地使用自动化，因此需要提前花费大量时间思考这个重要的设计点。

4.如何检测和处理容器故障?

基础设施的一个关键要求是，它不需要“保姆”，如果下降，它可以自我修复和自我恢复。因此，有一个过程来检测故障是最重要的，以及一个计划，当它发生时将如何处理。例如，无论是通过网络检查还是日志解析，都必须有一个预定义的过程来检测不再运行的容器应用程序。另外，应该有一个定义的过程，用一个新的替换容器作为一个可能的解决方案。虽然这个过程有许多方法，但设计点是通过自动化来确保满足要求。

5.每个微服务的代码如何被组织?

我们需要一个完全自动化的流程来构建和部署新的服务。然而，如果服务的数量很大，那么管理就会变得很麻烦。因此，应该创建多个版本的进程(每个服务一个)。在这些情况下，每个过程必须保持均匀。

一个非常重要的决定就是每个微服务的结构如何。例如，Dockerfile应该始终出现在完全相同的位置，而且Dockerfile应该包含该服务的特定内容。同样，其他文件(如Docker撰写文件或AWS ECS的任务定义)应始终放在同一个地方。跨所有服务，以便流程可以以均匀的方式一致运行。

技术考虑：

6.将使用什么工具在计算节点上安排容器?

调度程序是重要的工具，因为它们分配执行作业所需的资源，将工作分配给资源和业务流程，确保在需要时可以使用执行工作所需的资源。容器编排有许多工具选择。通常考虑的是：针对AWS客户的ECS，以及Docker Swarm或Kubernetes为那些希望与供应商无关的解决方案的客户。企业有几个角度来决定，包括可移植性，兼容性，易于安装，易于维护，即插即用的能力以及整体解决方案。

7.在同一服务的容器之间使用什么工具来平衡请求?

高可用性和在环境中拥有多个容器服务的能力使得每个微服务支持多个容器至关重要。对于非集群服务(例如，内部开发的基于Web的微服务)，需要一个外部负载均衡来平衡同一服务器上不同容器之间的流量。

这是一项重要的技术决策，应该进行彻底的评估。评估中有一些突出的设计要点：会话粘性的要求;计划拥有的服务数量;每个服务的容器数量;以及想要的任何Web负载均衡算法。

8.将使用什么工具将流量路由到正确的服务?

此设计点与负载均衡紧密结合，因为它直接解决了应用程序负载均衡问题。如前所述，每个服务分配单个URL或子上下文。当流量达到微服务集群时，另一个任务是确保进入的流量被传送到给定流量所针对的URL的正确的微服务。

哪个工具最适合应用程序负载均衡。可能要求做出正确决策的两个关键问题是，计划拥有多少个微服务，以及希望的路由机制复杂度。

9.什么工具将用于加密?

随着时间的推移，特定应用中的微服务数量增加，应用越来越多地依赖于SaaS扩展解决方案，安全性同时变得非常重要，更难于管理。对于微服务来进行通信，他们通常依靠证书和API密钥来对目标服务进行身份验证。这些API密钥，需要安全和谨慎地进行管理。随着它们的激增，传统的解决方案，如在部署时手动插入，不起作用。坦白说，管理的密钥太多了，微服务需要自动化。

企业需要通过自动化方式来解决需要它们的容器的加密。为保存加密存储建立内部解决方案，可以即时解密，并使用环境变量将其注入容器内。

你对这个技术问题的回答取决于你的加密有多少?你期望这个数字如何增长?安全和合规需求;以及如何愿意更改应用程序代码以方便处理。

10. SSL将在哪里终止?

一个经常出现的问题，特别是在服务网络流量的微服务上，SSL应该在哪里终止?要考虑的典型设计因素包括安全和合规要求。典型的选项是应用程序或网络负载均衡

某些合规举措，如HIPAA，要求所有流量都被加密。因此，即使在负载均衡上进行解密，也需要在将其发送到运行应用程序的容器之前重新加密。另一方面，在负载均衡上终止的优点是你拥有处理SSL证书的中心位置。当SSL证书过期或需要改变时，以便其尽量做少的更改。

作出设计决策时要考虑的因素包括具体合规性和安全性要求;应用程序加密和解密数据的能力;容器编排平台，因为有些人能够无缝地加密数据。所有上述的组合应该是你SSL终止决定的基础。

正确的选择将对企业的微型服务架构的成功具有长期的影响。设定正确规划，基于Docker的微服务是非常重要的。

本文作者：佚名

来源：51CTO