当微服务变成黑暗服务时

微服务很棒，许多公司来谈论它如何用于扩展团队，产品等

微服务也有阴暗面，作为程序员，您应该在骑车之前就了解它。

在这篇文章中，我将分享有关微服务的一些神话/阴暗面

• 我们需要大量的微服务

在创建任何新的微服务之前，请考虑一下分布式计算，因为大多数微服务都是远程过程。 首先定义“ micro”在问题上下文中的含义，它可以是代码行，功能或部署等

• 命名微服务将很容易

计算机科学只有两个复杂的问题，其中一个是“命名”，很快就会有100多个选项而用光。

• 非功能需求可以稍后完成

从一开始，突然的非功能需求（例如延迟，吞吐量，安全性，可靠性等）就变得非常重要。

• 多种语言的编程/持久性或某种多边形

软件工程师喜欢尝试最新的尖端工具，因此他们被我们可以使用任何语言，任何框架或任何持久性的神话所迷惑。

考虑一下多晶硅所需的技能和维护费用。 如果您有超过2/3的东西，那么它就不会适合您，您必须承担传呼机的职责。

• 监控很容易

这是关于微服务的最被忽略的事实之一，并且是事后才想到的。

为了进行简单的调查，您必须登录多台计算机，查看日志，确保在服务器等上获得正确的时间。

没有适当的监视工具，您将无法做到这一点，您需要ELK或DataDog类型的东西。

• 读写很容易

现在，您在分布式事务世界中，这件事也被忽略了，这不是一个好地方，要解决这个问题，您最终需要一致的系统或不可用的系统。

• 一切都安全

现在，一项服务正在使用API​​与另一项服务进行通信，因此您需要一个良好的身份验证系统来确保您的系统安全。 如果您在财务系统中工作，那么您将花费更多的时间来回答与安全性相关的问题。

• 我的服务将永远保持下去

无论您拥有多么优秀的程序员或基础设施，这都永远不会发生，服务将中断，现在您在中间件领域（Kafka，ActiveMq，ZeroMQ等）来处理此问题，因此可以在服务不可用时将请求排队。

• 我可以添加断点来调试它

这是不可能的，因为现在您处于远程过程中，并且不知道单个请求涉及多少微服务。

• 测试将是相同的

测试与单片测试从来都不一样，您需要更好的自动化测试来摆脱测试难题。

• 没有代码重复

随着您添加更多服务，代码共享变得困难，因为对某些通用代码的任何更改都需要进行良好的测试，并避免许多团队开始重复代码。

• 通过HTTP的JSON

这是所有微服务都必须在Http上拥有Json并且面向用户的最大神话之一。

这导致针对每个微服务的基于REST的API爆炸式增长，这就是为什么许多系统运行缓慢的原因，因为它们使用了没有类型信息的基于文本的协议。

您想摆脱微服务的反模式的一件事是，重新考虑您是否真的需要每个服务都使用Json / REST，或者您可以使用其他优化的协议和编码。

• 版本控制是我祖父的工作

由于大多数微服务都是远程进程，因此您必须附带请求/响应规范，并且必须管理版本以实现向后兼容性。

• 团队沟通保持不变。

这就像房间里隐藏着的大象，需要更多服务，需要更多的团队沟通，以使他们了解最新版本，运行版本，损坏之处等。

您可以拥有更多的孤岛，因为没人知道整个系统

• 您的产品属于google / facebook / netflix规模

这就像您永远不会中奖的购买彩票。

如果您不能编写像样的模块化单片，则不要尝试微服务，因为这一切都是为了获得正确的耦合和内聚。 模块应松散耦合且内聚力强。

微服务没有免费的午餐，如果您做错了，那么您将支付加价：-)

翻译自: https://www.javacodegeeks.com/2018/10/microservices-becomes-darkservices.html