微服务：神话、疯狂还是魔力？

目录

• 引言
  • 喝下迷魂汤
  • 现实检验
  • 每个解决方案都会带来新问题
• 现状
  • 意大利面条式代码和非规范化数据库
  • 微服务来解救：提取，而非重构
• 微服务神话
  • 降低运营成本
  • 降低开发成本
  • 微服务更好
  • 越小越好
  • 微服务不等于无服务器
• 问题与指导
  • 性能下降
    • 指导
  • 部署
    • 指导
  • 测试
    • 指导
  • 日志记录
    • 指导
  • 监控
    • 指导
  • 版本控制
    • 指导
  • 异步调用
    • 指导
  • 有保障的消息传递
    • 指导
  • 异常处理
    • 指导
  • 安全
    • 指导
• 结论
• 参考文献
• 历史

引言

那么，“微服务”到底是什么？它又为何如此喧嚣？维基百科提供了一个相当不错的定义：

微服务是一种软件开发技术——一种面向服务架构（SOA）的变体，它将应用程序构建为一系列松散耦合的服务。在微服务架构中，服务是细粒度的，协议是轻量级的。将应用程序分解成不同的较小服务的好处在于它提高了模块化。这使得应用程序更易于理解、开发、测试，并且对架构侵蚀更具弹性。它通过允许小型自治团队独立开发、部署和扩展各自的服务来实现并行开发。它还允许通过持续重构来形成单个服务的架构。基于微服务的架构支持持续交付和部署。¹

喝下迷魂汤

如果你喝下迷魂汤，这里的关键词是：

• 松散耦合的服务
• 细粒度
• 轻量级
• 模块化
• 弹性
• 并行开发
• 可伸缩

讽刺的是，从面向对象编程/架构/设计开始，我们听到的几乎是相同的口号，那么为什么微服务现在突然成为（之一）解决尚未解决问题的流行方案？三个答案：

1. 像微软、谷歌和亚马逊这样的公司通过提供微服务“无服务器”计算可以从中赚钱。
2. 虽然这是一种工具，并且确实很有用，“这将解决你所有问题”的诱惑力始终是一种诱人的警笛声，管理者和程序员都喜欢新技术的诱惑部分。
3. 最后，也是可悲的是，程序员普遍编程水平很差。但是，一个糟糕的程序员并没有学习如何成为一个更好的程序员，而是通过选择带有人工色素的甜饮料来保持糟糕，它承诺会让他们感觉更好。

现实检验

现实是，你几乎总是**不需要**微服务就能实现上述“圣杯”，你只需要一个体面的架构。所以让我们重新定义微服务：

微服务：又一个概念，旨在修复糟糕软件开发者创建的糟糕架构，并为那些依赖他人糟糕软件实践的大企业赚钱。

Medium上的一篇文章写道：“从概念上讲，微服务扩展了工程师几十年来一直采用的相同原则。”² 错了。这些原则已经**存在**了几十年，但“采用”？几乎没有。

同样，New Relic上的一篇文章指出：“使用微服务时，您将软件功能隔离到多个独立模块中，这些模块各自负责执行精确定义、独立的任务。这些模块通过简单、普遍可访问的应用程序编程接口（API）相互通信。”³ 等等，我们需要微服务才能实现这一点吗？这不是OOP的承诺吗？这不是MVVM、Angular等所有新潮框架的承诺吗？

每个解决方案都会带来新问题

当然，你用来掩盖疾病症状的止痛药可能暂时有效，但根本原因并未解决，并且它们可能会引发更多问题。按照这个糟糕的比喻，微服务本身也带来了一些相当沉重的问题：

• 服务之间频繁的消息传递和/或大消息可能导致性能下降。
• 部署更加复杂（更多的部署脚本、更多的版本、版本之间的不兼容性）。
• 测试：应该更简单，但不一定，特别是当您突然需要50个微服务都运行才能测试一个微服务时。
• 日志：好吧，您如何协调每个微服务生成的所有不同日志和时间槽？使用集中式日志记录器？也许是一个微服务日志记录器，哈哈？
• 版本控制：突然，一个微服务的更改导致依赖微服务的递归更改，您发现您所谓的模块化架构实际上是代码、项目和解决方案的碎片化地狱，它们仍然纠缠不清。
• 对微服务的异步调用：没错。似乎没有人愿意谈论这个。
• 有保障的内部通信：您拥有基于服务器或“无服务器”的微服务，可能在本地硬件、远程硬件、虚拟机和基于云的服务器混合环境中执行，并且通信链中的某个环节出现故障。糟糕。
• 异常处理：没错。同样，似乎没有人愿意谈论这个问题。
• 安全性：突然，您可能会发现自己需要维护不同服务器的SSL证书，对每个“无服务器”引擎进行防火墙设置，确保已关闭端口，并可能暴露在额外的公共TCP/IP消息传递和身份验证/授权问题中。作为一个安全专家，这可能只是冰山一角。

因此，与其写一篇关于微服务有多么出色以及如何实现它们的传统文章，不如让我们来处理它们带来的问题，并找出使用微服务的真正原因。

现状

让我们从一个有点理想化（但不完美）的、非常常见的单体Web应用程序概念开始。

诚然，作为高级别块和箭头，这看起来相当不错。在这里，Web服务器负责：

• 实时日志和指标
• 认证和授权
• 静态内容
• 用户账户管理
• 客户端报告（内置和自定义）
• 与第三方服务接口，例如GIS、社交媒体、新闻/天气/股票服务，甚至与客户端本地硬件（支付终端、指纹识别器、条形码扫描仪等）进行通信
• 自动化流程，例如定期使用报告、数据清理、异地备份（尽管通常由完全独立的过程处理）
• 其他服务：支付处理、短期有状态数据管理（如购物车）等
• 应用程序/业务行为和逻辑
• 搜索/查询和长期有状态数据管理，可能包括客户端定义的自定义查询脚本
• 跟踪数据随时间变化的审计跟踪

事件，即客户端的端点调用，触发了这些途径和流程的大多数。

意大利面条式代码和非规范化数据库

除非Web应用程序非常小，否则我个人从未见过一个具有清晰架构的大规模Web应用程序。它们可能存在，但我不得不处理的大规模Web应用程序是复制粘贴代码（前端和后端都有）、缺乏明确定义和文档化的API以及缺乏清晰定义的服务边界的噩梦，即使这些服务是直接在主应用程序或支持程序集中实现的逻辑服务。这与以下因素无关：

• 编程语言（C#、Python、Ruby等）
• 后端支持框架（MVC、MVVM、Django、Rails等）
• 前端语言和支持框架（纯Javascript、TypeScript、ASP.NET、Angular等）

可悲的是，似乎很少有开发人员和开发团队有能力创建设计良好、编写良好的应用程序。更重要的是，这个结论与团队是采用敏捷、瀑布还是临时开发实践无关。此外，数据库架构也未能幸免于这个问题，非规范化数据库和被重新用于其他值的列（而非其原始字段名所暗示的值）似乎是常态。

最佳情况下，典型的端点实现通常看起来像这样：

[VariousAttributes]
public object SomeEndpoint(SomeObject thatWasDeserialized, 
string decodedParam1, 
int decodedParam2, 
double etc)
{
  MaybeDoSomeValidation();
  MaybeThereAreMapReduceFilterOperations();
  MaybeThereIsSomeBusinessLogic();
  DoSomeDatabaseOperation();
  var result = SerializeTheResult();
  return result;
}

上面的代码看起来还不错，因为工作流的每个步骤都有方法调用。**但这不现实**。相反，那些美好的方法调用最终都变成了代码行，导致端点方法有数百行代码，可能包含硬编码的SQL，特定于该端点调用的业务逻辑，以及结果的自定义序列化，通常返回整个对象而不是客户端所需的特定数据，从而浪费带宽并过度利用服务器端CPU。但我写这篇文章不是为了讨论好的架构，而是为了讨论微服务。

微服务来解救：提取，而非重构

你的网络应用程序没有架构，没有文档齐全且定义良好的内部API，当你需要添加更多功能、用户和修复现有问题时，你正处于“死亡行军”⁴之中，这些问题**并非由管理层造成，而是由我们的开发兄弟**，甚至是我们自己造成的。你无法重构代码，因为没有办法测试它，而且它与其余代码纠缠不清。但是你**可以**提取代码中可用的部分，并在足够高的层次上，将端点调用重定向到新的微服务中。

所以，这就是你考虑使用微服务的残酷真相：*它提供了从头开始的机会，每次提取一小部分，并希望凭借你第一次（或第二次、第三次）犯错的经验来重写它们。* 是的，这可以在不依赖微服务的情况下实现，但创建真正计算隔离的纪律可能不存在，除非你使用像微服务这样强制执行这种纪律的范式。

您可能有机会利用更先进的技术——您的代码库有多少被锁定在两三年前的框架版本中，因为升级框架会破坏一切？尽管理想情况下，任何第三方框架的依赖都应该抽象化。您可能有机会应用更好的OOP原则（抽象、代码重用等）。鉴于您正在从一碗意大利面中提取一根面条，您很可能会有机会编写一些API文档。

理想情况下，如果操作得当，您将得到一个真正的**服务**，它：

• 可在多个应用程序中重复使用
• 可以维护和升级，而不影响应用程序的其余部分
• 易于模拟以进行系统级测试
• 文档齐全
• 经过良好测试

重构（“重组现有计算机代码——改变分解——而不改变其外部行为”⁵）本身并不能实现这个目标，因为坦率地说，微服务所实现的**通常**会改变外部行为：

• 客户端可以直接调用微服务（端点更改）。
• 您可能最终会更改数据接口，使其更精简。
• 您可能需要额外的端点调用来扩展/改进/简化微服务行为。
• 错误处理可能会改变或改进。

由于只提取了单体应用程序中非常小的一部分，改变前端（或后端穿透调用）更容易，因为更改的范围有限。但这个过程不是重构——您正在提取代码，理想情况下将其从原始代码库中移除，并将其放入自己的计算孤岛或“盒子”中，在那里它独立存在并希望能快乐。

所以让我们完善微服务的定义：微服务是减少当前应用程序单体架构的有效途径，通过将逻辑服务提取为具体且离散的实现。

微服务神话

降低运营成本

您已经拥有一个“始终在线”的服务器来提供网页服务。为什么要为像不常调用的端点这样的东西创建单独的实例呢？在基于云的架构中，降低当前服务器“系统”成本的唯一方法是，如果能够以某种方式减少虚拟服务器的内存、处理器架构、带宽要求、CPU性能和CPU利用率，使得成本节约（您所支付的费用）大于在“无服务器”微服务中处理端点调用的成本。说起来容易做起来难，而且您是否正在省钱只能通过时间和比较转换为微服务前后的历史数据来确定。

降低开发成本

New Stack 上的一篇文章很好地阐述了这场争论：

“这完全取决于你在做什么，”他 [Christ Priest] 说。“微服务的持续成本远低于基于单体系统的成本。我认为你的成本可以轻松降低90%以上。这取决于最初的情况有多糟糕。”但 Priest 说，节省的成本不仅仅来自使用 Kubernetes 等容器系统。节省的成本还来自开发人员文化的改变。在一个单体基础设施中，一家公司可能有100名开发人员在同一个代码上工作，这可能是一场噩梦，因为他们的改动与其他人不协调，增加了复杂性和问题。但在微服务方法下，开发人员可以独立地在代码的不同部分工作，这允许用更少的重叠和复杂性完成更多工作。Priest 说：“让团队转向微服务的工作方式，你可以大大提高生产力。”但他再次强调，很难估计这种有益举措所带来的节省。⁶

我不确定我是否会相信“90%”这个数字，但这是一个有趣的观点——正如我前面提到的，通过将一种范式强加给整个开发团队，你可以强制进行文化变革，从而真正节省资金。不是在服务的托管方面，**而是在开发和维护成本方面**。不幸的是，微服务带来的新问题肯定会增加成本，特别是在以下情况下：

• 开发人员缺乏微服务经验，可能需要学习容器系统等新技术。
• 开发人员不足，需要引入所谓的专家来教育他们如何处理本文开头提到的问题。
• 重新培训开发人员以使用“新方式”。
• 您的IT部门需要学习如何支持和保护容器、无服务器计算引擎等。
• 您的支持团队需要了解如何以可能不同的方式检查日志。
• 您的部署团队需要编写和支持新的部署脚本。
• 随着新的端点公开或内部暴露，您的代码库可能需要通过重新认证流程。
• 您的安全团队需要审查和监控微服务的安全漏洞。

所以，是的，“很难估计节省的开支……”，这使得上面引文中句子的后半部分：“……这种有益的举措”，变得可疑。人们措辞的方式很有趣，当你真正阅读他们所说的话时。

微服务更好

CIO写道：

“作为面向服务架构 (SOA) 的一种变体，微服务是一种将应用程序分解为松散耦合服务的架构风格。通过细粒度服务和轻量级协议，微服务提供了更高的模块化，使应用程序更容易开发、测试、部署，更重要的是，更容易更改和维护。”⁷

重点在于它使应用程序更容易：

• 开发
• 测试
• 部署
• 更改和维护

并非如此。开发并不一定更容易，因为微服务（如前所述）需要重新思考/重新设计应用程序如何划分为独立服务以及这些服务如何相互通信。测试也不更容易——测试单体应用程序的相同问题也存在于微服务中：您是否有可以在其中模拟类/方法的架构？您的代码是否以足够小的单元编写，以便您能够真正编写单元测试？从定义上讲，微服务限制了“系统”测试，因为您只测试了“系统”的一小部分。部署也不更容易。每个微服务都需要某种部署脚本或流程，并附带其自己的、希望是唯一的部署凭据。您现在有许多脚本/流程，而不是单个脚本/流程。如前所述，一个微服务中的更改可能需要更新依赖的微服务，这会使更新协调复杂化。买家自负！

越小越好

正如 The New Stack 文章所说：

同样明智的做法是避免创建过于微小的服务，他 [Christ Priest] 补充道。“每个新服务都有开销，应将其考虑在内，并与解耦架构所带来的速度优势进行平衡。像 Kubernetes 这样的工具可以帮助减少这种开销，并与微服务方法相辅相成。”同时，使用容器平台而不是仅仅使用原始虚拟机也可以提高效率并降低成本，他说。“这本身不是微服务，但通常与这种架构搭配使用。利用率从不到10%上升到不到50%并不罕见。这可以从减少硬件、数据中心或云使用以及减少管理成本中带来巨大的节省。”⁶

我遇到的一些“无服务器”解决方案是围绕每个端点一个微服务的思想构建的。如果您想动态支持具有不同子路径（`foo/bar` 和 `foo/foo`）的多个端点（而不是手动将函数映射到API网关），您最终不得不编写一个微型路由器来支持它。我可能错了，但亚马逊的AWS Lambda就是这样，它要求您解析输入字符串或流并创建自己的路由器来处理子路径。不确定Azure计算函数的情况。

无论如何，“无服务器”解决方案通常不是微服务的理想平台，因为无服务器解决方案实际上更像是一个“纳米”解决方案——通常实现一个作为内部或公共URL暴露的功能。微服务的挑战之一是不要让它们太小，但同时也要避免成为仅仅是单体主体的延伸的单体臂。

微服务不等于无服务器

有些微服务是无服务器计算的理想候选者：“无服务器计算（或简称无服务器）是一种执行模型，其中云提供商（AWS、Azure或Google Cloud）负责通过动态分配资源来执行一段代码，并且只按代码运行所使用的资源量收费。”⁹ 无服务器平台的一个很好的用例是当您的微服务不常被调用和/或微服务的计算时间超过了容器冷启动¹⁰的性能开销时。这本身就是一把双刃剑，因为大多数云提供商会在几秒钟内使无服务器函数调用超时（对于某些提供商，如AWS，此超时是可配置的）。因此，根据微服务正在做什么以及它被调用的频率，确定无服务器平台还是服务器平台最适合该微服务就成为了一个决策点。

问题与指导

我不能将这一部分称为“问题和解决方案”，因为不一定存在真正的解决方案。相反，更多的是一组在实施基于微服务的架构时应遵循的准则。所以让我们来看看每个问题。请记住，这将是对问题和建议指导的相当高层次的审视。关于微服务问题的优秀文章可以在Medium上找到：《微服务架构——你必须解决的问题》⁸，作者是 Justin Miller。另请参阅微软的《设计面向微服务的应用程序》。¹¹

性能下降

显然，任何时候一个进程需要与不共享相同物理内存空间的另一个进程通信时，都必须发生某种数据的序列化/反序列化。这需要时间。微服务之间通信的通常方式是通过HTTPS和REST调用，通常使用JSON作为序列化格式。当然，返回的数据需要由微服务序列化，并由目的地反序列化。

指导

• 只传输微服务端点实际执行任务所需的数据。不要序列化整个对象结构，这也会在发送方和接收方之间造成纠缠。
• 考虑使用自定义序列化器。JSON 和 XML 都非常冗长。您真的需要将键和标签作为人类可读的文本，还是可以以只有机器才能理解的二进制格式发送数据？
• 禁用压缩。小数据包的压缩会浪费CPU时间，几乎无法实现任何压缩。

部署

部署不应该复杂，但你可以随心所欲地使其复杂。避免复杂性！

指导

• 为所有微服务制定一致的部署策略。不要用不同的脚本语言编写脚本。不要使用开发工具（如 Visual Studio）进行部署。
• 考虑一个简单的前端，让你可以勾选想要部署的内容。工具应该通过减少打字、鼠标点击和隐藏复杂性来简化生活。
• 编写微服务时，避免微服务调用嵌套。相反，让一个主入口点顺序（或异步）调用每个微服务。

关于最后一点：

错误

更好

这种实现更好，因为：

• 它降低了错误处理的复杂性。
• 允许对每个微服务进行异步调用。
• 您只测试一个微服务，而不是整个嵌套结构。
• 解耦了每个微服务之间的依赖关系，使部署更容易。

测试

测试微服务应该不会比测试单体应用程序更困难。事实上，测试应该更容易，因为微服务应该尽可能地实现一组有限的端点和一小组行为。测试问题与任何一段代码都非常相似：

指导

• 微服务端点只应负责反序列化、调用较小的“单元”方法和序列化结果。不要用所有反序列化、业务逻辑、数据库调用、第三方调用和序列化来实现端点。

错误

Stream Endpoint(Stream input)
{
  var deserializedData = Deserialize(input);
  ... inline code that makes DB calls ...
  ... inline code that makes third party calls ...
  ... inline business rules ...
  ... inline further map/reduce/filter ...
  return SerializedResult(whatever);
}

更好

Stream Endpoint(Stream input)
{
  try
  {
      var deserializedData = Deserialize(input);
      var result = DoSomeWork(deserializedData);
      return SerializedResult(result);     
  }
  catch(Exception ex)
  {
    return SomeUsefulInfoAboutTheException(ex);
  }
}

ResultObject DoSomeWork(InputObject obj)
{
  dbService.DoNecessaryDBStuff(obj);
  thirdPartyService.CallIt(obj);
  businessRules.RuleA(obj);
  businessRules.RuleB(obj);
  additionalFiltering();
}

这里需要注意的重要一点是，即使是微服务，作为内部服务，也使其内部服务可模拟，这是朝着可进行单元和系统测试的代码迈出的一大步。

日志记录

一旦您走上微服务之路（无论好坏），您很快就会拥有足够多的微服务，使得日志记录成为一种新的复杂性，特别是如果您对其他微服务进行嵌套调用，如上所述，如果可能的话，您应该像躲避瘟疫一样避免它！即使是对不同微服务的串行调用，特别是异步调用，也会在日志同步和解耦方面成为一个令人头疼的问题。

指导

• 使用第三方日志记录器，如 PapertrailApp (现为 Solarwinds) 或类似的 LogEntries。更多选项 在此。
• 包含标识以下内容的标签：
  • 微服务名称和版本
  • 入口函数
  • 可能的参数——如果您包含参数，请考虑安全问题并加密/修改某些参数）
• 不要用您在开发/调试微服务时使用的一次性调试内容污染您的日志
• 如果你不清楚为什么要记录某些东西，那就不要记录。
• 实施不同的日志记录级别。
• 始终记录异常，但要包含有用的信息。堆栈跟踪通常无用，因为没有调试信息（行号、代码模块等）。异常需要细粒度，以便您真正知道是哪个地方抛出了异常。

监控

与日志记录一样，您可能会发现自己正在查看来自多个不同云提供商或需要您在同一云提供商中手动检查的独立URL的图表。以这种方式监控每个服务既耗时又无效。

指导

• 创建警报，这样您只需在超出预期操作参数时才需要查看。
• 查看云平台提供的 API，以便您可以创建一个工具，将监控统一到一个集中的实时应用程序中。

版本控制

在单体应用程序中，更改方法签名会立即识别出所有需要修复的地方（至少对于一个健全的强类型语言而言）。而在微服务架构中，您会失去这种优势，因为与前端一样，通信模式通常是 HTTPS REST 调用。这意味着您正在序列化一个约定好的数据结构，但没有编译时确定该结构是否已更改的方法。因此……

指导

• 如果可能，使用一个通用类（在DLL中定义），调用者和微服务都用它来发送和返回信息。这样，如果您在一个地方更改了结构，您就可以在编译时收到破坏性更改的通知。
• 数据进入消息体。不要使用URL参数。URL参数太不结构化，容易导致破坏性更改。
• 有一个单一的调用点（方法或函数）来调用微服务。这样，如果你必须更改数据结构，你可以在一个地方修复它，并从那里向后处理依赖关系。
• 如果绝对必要，创建一个全新的端点，以便（至少暂时）您可以同时维护旧的调用和新的调用。尽快移除旧的调用。

异步调用

在某个时候，您可能需要处理一个服务，该服务启动一个长时间运行的进程，客户端希望在进程完成时收到通知。这是一个明显的异步调用候选。不太明显的是异步调用几个短时运行服务的潜在好处。这两种情况都有些边缘——理想情况下，您的服务调用应该在几秒钟内返回，并且肯定在REST调用放弃响应之前。长时间运行的进程（超过REST调用超时的进程）除了在进程完成时通知调用者之外，别无他法。如果从服务器调用，并且假设客户端不关心调用何时实际完成，您只需将结果 POST 回去：

当客户端**确实**关心时，问题就出现了。这里我们有两种情况：

1. 短时运行的微服务进程，我们无需担心REST调用超时。
2. 长时间运行的微服务进程，超出了客户端的REST调用超时。

在第一种情况下，我们可以这样做：

Stream EntryPoint()
{
  var tasks = StartAllAsyncTasks();
  Task.WaitAll(tasks);

  return someResult;
}

当然，当服务运行时间过长导致REST调用超时时，这将完全失败。现在怎么办？鉴于本文的背景是您正在托管一个Web应用程序，“客户端”当然是浏览器。如果客户端是另一个服务器，解决方案就更容易了——服务器可以在进程完成时提供自己的回调URL，这可能看起来像这样：

真正的问题在于浏览器客户端。除了轮询（令人不快）之外，我们不得不求助于Websocket来通知客户端完成。这可能会导致一个复杂的“结果返回”路径，具体取决于客户端调用的接收位置。如果websocket连接是向服务器打开的，那么服务器必须在该连接上响应：

如果客户端直接与微服务打开 websocket，过程会更简单：

指导

• 短时运行的微服务是理想的，它允许您实现异步调用，而无需单独的“回调”通信通道来通知服务完成。
• 如果您有一个长时间运行的微服务，请考虑客户端是否需要收到完成通知的选项，如果需要，最佳方法是什么。虽然我不喜欢轮询，但在某些情况下，它可能是最好和最合适的解决方案。
• 让客户端直接调用微服务，而不是通过中间层服务器。
• 在等待结果时，当websocket连接失败时，提供一个回退/恢复实现（如轮询）。
• 异步实现最适合“读”操作。请参阅下一节关于“写”操作的内容。

有保障的消息传递

作为上一节的延续，有时您需要有保障的消息传递，无论是即发即弃还是即发即确认的实现。消息队列，如RabbitMQ¹³和MSMQ¹⁴，是“服务器”之间众多选项中的两个。对于Javascript（非Node.js）Web应用程序客户端选项，请查看STOMP¹⁵等选项。

指导

• 有保障的消息传递的目的是，当客户端调用服务器时，特别是在更新涉及一个或多个微服务的数据时，您希望确保在某个时候（特别是在异步操作中）消息确实由微服务处理。客户端可能无法收到服务器端“内部”故障的通知。
• 您应该问的问题是，为什么要使用异步且可能多层的服务器-微服务架构来持久化数据？答案是，除非您有非常充分的理由，否则您可能不应该这样做。但如果您必须这样做，请考虑使用消息队列来保证写入/更新/删除操作。
• 实际上，没有任何东西能阻止用户在数据传输过程中关闭浏览器。这让生活充满了冒险，虽然这是用户的错误，但你会为丢失的数据承担责任。所以数据写入真的应该直接发送到“服务器”，该服务器要么正在写入数据，要么能够保证在某个时候数据会被写入。

异常处理

微服务中的异常可能难以诊断和调试，因为任何有用的信息要么必须向上冒泡到可以检查或记录的顶层调用，并且再次提供足够有用的信息以理解问题。

指导

• 制定一致的异常处理策略。这应包括：
  • 一个单独的日志，仅用于异常。
  • 一种一致的方法来收集与异常相关的信息，例如输入参数和异常消息本身。
• 由于调试信息通常不可用：
  • 包裹整个API方法的try-catch块作用不大。在API方法的每个“逻辑”部分使用try-catch-throw。
• 请阅读我的文章，了解如何记录异常。

安全

我不是安全专家，甚至也不是新手。这里的指导是我从其他来源拼凑起来的。

指导

• 使用HTTPS！确保HTTP已禁用！
• 对非公共API入口点使用身份验证/授权。这是您的最后一道防线，但却是重要的一道。
• 需要有人**彻底**了解：
  • 如何设置安全策略
  • 如何测试这些策略是否正确设置
  • 如何及时了解提供商的策略更新。
• 定期审计您的策略。
• 创建策略时，使用你能达到的最严格的权限。
• 如果您是自托管，请正确设置防火墙。

结论

不要被微服务的炒作所迷惑。这包括降低成本和提高生产力的承诺。不要盲目相信辅助技术。这包括Docker、Kubernetes、AWS、Google和Microsoft。您完全可以在DigitalOcean¹²上的Linux操作系统中托管一个微服务，每月5美元，运行C# .NET Core代码。三思而后行，并有充分的理由。使用微服务作为开始解耦单体应用程序的方法**是一个**很好的理由。

参考文献

¹ - https://en.wikipedia.org/wiki/Microservices
² - https://medium.com/@justinamiller_1857/microservices-architecture-problems-you-will-have-to-solve-4153cfbde713
³ - https://blog.newrelic.com/technology/microservices-what-they-are-why-to-use-them/
⁴ - https://en.wikipedia.org/wiki/Death_march_(project_management)
⁵ - https://en.wikipedia.org/wiki/Code_refactoring
⁶ - https://thenewstack.io/microservices-pricing-whats-it-all-going-to-cost/
⁷ - https://www.cio.com/article/3201193/7-reasons-to-switch-to-microservices-and-5-reasons-you-might-not-succeed.html
⁸ - https://medium.com/@justinamiller_1857/microservices-architecture-problems-you-will-have-to-solve-4153cfbde713
⁹ - https://serverless-stack.com/chapters/what-is-serverless.html
¹⁰ - https://medium.com/@kevins8/benchmarking-lambdas-idle-timeout-before-a-cold-start-cbfd7ef97c18
¹¹ - https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/microservice-application-design
¹² - https://www.digitalocean.com/
¹³ - https://rabbitmq.cn
¹⁴ - https://en.wikipedia.org/wiki/Microsoft_Message_Queuing
¹⁵ - https://rabbitmq.cn/web-stomp.html

历史

• 2019年7月15日：初版