黑暗城堡
微服务很棒，许多公司来谈论它如何用于扩展团队，产品等
微服务也有阴暗面，作为程序员，您应该在骑车之前就了解它。
在这篇文章中，我将分享有关微服务的一些神话/阴暗面
- 我们需要大量的微服务
在创建任何新的微服务之前，请考虑一下分布式计算，因为大多数微服务都是远程过程。 首先定义“ 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
黑暗城堡