创建一个微服务？首先回答这10个问题
原文作者：Datawire
在表面上构建微服务看起来很简单，但是创建微服务不仅仅是启动在容器中运行的代码并在它们之间发出HTTP请求。这里有10个重要的问题，你应该在开始开发之前（当然它还没有被部署到生产环境中）就回答关于任何新的微服务的问题 - 。
1.如何测试？
当涉及到测试时，微服务有一系列有趣的优点和缺点。一方面，测试代表定义明确功能的小型服务的单元测试可能比测试整个单一应用程序容易得多。另一方面，验证由许多微服务组成的整个应用程序的质量可能代表了大量的测试复杂性：不是运行单个命令来测试在一个进程中运行的代码，而是大量的集成相关组件先健康地运行，并在整个测试过程中保持运行。
这种新的微服务是否可以单独进行测试（使用单元测试或模拟依赖关系），还可以在更加实际的“集成”或“分段”环境中进行测试，在这种环境中，它将与生产中涉及的相同类型的服务相连接。测试是否包含性能验证和失败模式？所有的测试都会自动完成吗？还是人类必须参与运行并检查测试结果？以一种简单，快速和自动化的方式进行微服务测试将鼓励开发人员维护并防止“ 破窗 ”问题。
2.它将如何配置？
一旦新的微服务投入生产，它的内部行为会受到什么影响?这包括基础结构的更改(例如，更改池中线程的最小数量)和一些应用程序级别的更改（例如，通过翻转功能标志来启用新功能）。对于所有这些变化，了解服务是否需要重新启动才能生效是至关重要的。
当然，如果可能的话，构建一个在其生命周期中完全不需要改变配置的服务将是最理想的方法。
3.系统的其他部分如何消耗？
构建微服务没有多大意义，除非系统的其他组件使用它，因此理解它们如何使用微服务是至关重要的。
这些其他组件将同步或异步地与新的微服务交互吗?是否应该鼓励他们将响应缓存一段时间?什么是重试和幂等性？新微服务的正常运行时间SLA是否与系统中其他组件的正常运行时间SLA相匹配？
对于新微服务将提供的响应延迟，应该有明确的预期，使用微服务的组件应该知道这些预期。这样，当这些期望没有满足时，系统的其他部分可以决定触发超时、触发断路器或故障转移到服务的另一个实例。
4.如何保证？
除非是在高安全性环境中，否则大多数部署在防火墙后的微服务都不需要过分关注服务间安全性。在微服务之间添加大量的安全检查可以增加显著的操作复杂性，使生产问题很难调试和修复。由于维护、部署和保护一些正确签名的证书所需要的工作，甚至使用HTTP上的HTTPS进行服务间通信也可能是一个重要的维护开销。通常，更好的方法是允许流量在微服务之间畅通无阻，同时仍然应用合理的应用程序级别的身份验证和授权级别，当然还要保持非常安全的边界。
因此，系统中的其他组件很可能能够向微服务发送请求而不出问题，但它们可能仍然需要传递一些身份验证数据，这些数据表示发起外部用户，以便实际批准和处理请求。这绝不应该是明文密码数据，但它可以使用诸如JWT，OAuth，SAML或Auth0之类的技术。无论采用何种方法，该技术都必须非常清楚地记录下来，并且最好在客户端库或示例代码中捕获，以便其他开发人员可以轻松使用新的微服务。
5.它将如何被发现？
当一个新的微服务启动时，系统中的其他组件如何找到它?发现过程越简单，它的灵活性就越低，之后会遇到更多的问题。例如，最简单的方法(同时也是一种脆弱的方法)是将微服务的地址硬编码到依赖它的其他组件的代码或配置中。这可能会一直工作到服务的地址必须更改，或者直到服务的多个实例在其他区域可用为止。这当然不是一种推荐的方法。
使用诸如DNS名称之类的间接技术来隐藏微服务的地址会更好一些，但是这也有它自己的缺点:找到一个合适的TTL值,迫使名字重做决议,使DNS缓存行为一致,等。通过设计,域名没有考虑服务的可用性,这可能导致应用程序组件遵循一条通往一个IP地址,没有监听,浪费时间,导致运行噪音,他们试图找到一个工作实例。它也会让开发人员感到非常困难，因为使用DNS作为路由机制通常会导致开发人员的/ etc / hosts文件的临时修改。
在复杂的领域，高度可用的数据存储或数据同步服务（例如ZooKeeper）可能被用作微服务的注册表，这些服务目前仍然运行良好。但仍需要更多的技术投资，并且还应该谨慎对待，以确保发现服务本身不会成为单点故障（SPOF）。当微服务启动时，它们将自己注册到这个注册服务中，当它们关闭时，它们将自己删除。如果它们意外终止或陷入死锁，也必须自动从注册表中删除它们。记住，发现不仅仅是发现正在运行的东西——发现什么是不可用的也是很重要的。
6.随着负载的增加，它将如何扩展？
如果微服务在不断增长的应用程序中显示真正的价值，那么将会有越来越多的开发人员使用它，并且随着应用的不断增加，流量也会相应地增加。为新的微服务制定一个易于理解的扩展计划对您的操作团队非常有价值。
微服务会自动扩展吗？在内存中是否存在会使自动扩展和请求路由变得困难的状态（例如用户会话状态）？如果有的话，分拆策略是什么？
当微服务以当前的形式大规模扩展时，预先了解哪些部分将首先失败是有益的。对于由数据库支持的服务，计算能力(例如，自动伸缩组中的EC2实例)通常可以在数据库过载之前继续扩展。对于真正无状态的服务(例如，不读或不写到任何数据库的计算微服务)，第一个耗尽资源的可能是位于实例集群前面的负载均衡器。这两种方案都有解决方案，但是这些解决方案不一定要在部署microservice的第一个版本之前到位。但是，了解您的新微服务的局限性是很好的，这样您就可以知道在生产之前，可伸缩性上限的存在。
7.它将如何处理其依赖项的失败？
即使是使用非常小的有界上下文构建的微服务，也可能依赖于系统中现有的其他微服务或整体。例如，大多数应用程序事务都能够查找客户信息，因此，用于访问客户记录的服务通常是提供业务价值的大多数其他服务的依赖项。
如果您的新微服务依赖于这些其他服务中的任何一个，那么知道这些依赖关系失败时应该发生什么是至关重要的。使用一致的请求超时将是一个好的开始，但添加电路中断会更好。当事情无法防止惊群问题的场景时，依赖服务的所有者可能还希望任何消费者的使用指数备份之类的技术。
值得庆幸的是，这是一个更容易测试的场景，因为测试它仅仅需要依赖的缺失。然而，重要的是要记住，对依赖服务的API的调用有很多方法会失败，而且这些失败并不都以相同的方式表现出来。
8.系统的其余部分如何处理新微服务的失败？
根据在新的微服务的高可用性上已经进行了多少投资，以及取决于它支持的事务类型，这可能是最不值得关注的。例如，在UDP上异步发送数据的一个简单的操作日志微服务可能每次失败几分钟，而不会对应用程序中的主要业务事务造成任何中断。但是，如果一个微服务以同步方式处理信用卡事务，如果它完全失败，将会对电子商务系统造成严重破坏，而这应该是一个经过测试和准备的失败场景。
因此，即使一个范围很广的微服务（或其开发人员）不一定关心系统的其他部分将如何使用其新组件，系统级别对每个服务依赖于其他部分的意识只能帮助防止级联故障，也将有助于确保应用程序性能仍然是可以接受的。
9.如何升级？
相信像Docker这样的容器技术和像Ansible这样的部署自动化工具使升级变得微不足道，但但与这些工具提供的功能相比，微服务维护有更多的东西。
定义升级策略并确定您的微服务支持的部署复杂程度是非常重要的。诸如canary测试，blue/green部署，特征标记以及差异化响应等技术都需要花费超出新版本取代旧版本所需的简单滚动升级所需的时间和精力。
定义用于升级微服务的API的边界和策略对于依赖它的组件尤其重要。例如，只允许对API的JSON模式进行附加的更改，可以有效地允许服务的持续改进，而不要求服务的使用者遵循每次升级的同步。然而，在XML响应有效负载中添加新字段，当其消费者都在进行XML模式验证时，将会造成严重破坏。因此，如果新的微服务将定期升级以向其API对象添加越来越多的字段，请通过其文档明确地向服务的使用者明确说明。
最后，还需要知道，如果出现问题，如何回滚新的微服务，以及什么是“回滚有价值的标准”。
10.如何监测和衡量？
如果您的组织已经拥有用于应用程序监视的标准和工具，那么明智的做法是利用它们并在已经使用的监视生态系统中发挥良好的作用。当然，不要忽略它们，或者更糟糕的是，集成一个新的监控工具，而您的操作团队甚至还没有使用这个工具。
如果您的组织还没有使用高质量的应用程序监视系统，那么向应用程序添加一个新的微服务可以作为一个很好的强制功能来实现。对于习惯于监视大型单片应用程序的组织来说尤其如此，它们正开始向微服务体系结构迈进:对一组相互连接的微服务的操作监视需求要比单个大型单片微服务复杂得多。
无论选择哪种监控解决方案，无论是自主开发的，开源的还是商业的，最重要的是微服务的开发人员都可以完全访问其组件的监控和测量数据。如果没有这种可见性，就没有办法将反馈循环返回给开发人员，让他们知道如何在生产环境中改进他们的服务，当他们在深夜出现问题时，他们也无法轻松帮助诊断。
总结
虽然可能不需要对以上10个问题都有非常清楚的答案，但是考虑每个问题并意识到微服务可能具有的任何体系结构限制是很重要的。例如，您的新微服务可能首先在没有任何灾难恢复或区域故障容忍度的情况下部署，然后再进行升级以包含这种弹性。了解您的微服务目前能做什么和不能做什么是至关重要的，了解每个问题的答案将帮助您不断地改进它，直到它发展成为一个成熟的、有弹性的、可靠的系统组件。