微服务很难，构建可靠且可测试的微服务比大多数人认为的要难得多，有效地“测试”微服务需要大量的工具和远见。-许多（或大多数）公司组织都不需要Netflix / Uber风格的微服务。
宏服务Macroservices？
- -并非整体/单体monolith
- -有不超过20个开发人员/ 3个团队从事该服务（5个披萨规则？）
- -可能需要或不需要Monorepo。服务/存储库越少，依赖关系管理就变得容易得多（尽管仍然很简单）
- -更好的可观察性，调试
网友讨论：
去年，我们就Micro与Macro进行了广泛的讨论。尽管“千篇一律”的方法行不通，但关键是要了解并预见什么对业务至关重要。
需要考虑的几件事：
- -垂直与水平缩放
- -技术债务的严重程度
- -多少服务
- -API架构/基础设施/性能
- -服务的用户/客户使用情况
更大且可扩展（宏）的服务比小型和复杂的服务（微型）更好。
我认为人们仍纠结于部署模型的关注点分离和解耦。用micro / macro前缀的服务也无济于事。我们需要考虑有界的上下文，而不是大小。
此外，通过网络进行越来越多的分布式分发意味着您要冒数据完整性的风险。似乎范例已在转向事件溯源，事件溯源eventsourcing建立在数据库如何处理数据完整性的基础上。
我同意。我还注意到，当人们谈论ms时，他们首先想到的是可伸缩性。但是，我倾向于将ms视为扩展团队而不是系统的一种方法。例如，我可以提到两个披萨亚马逊的规则。
大多数认为自己需要微服务的人都希望两件事中的一项：
- 能够轻松地水平扩展
- 围绕功能边界分离开发团队。
这些都不需要微服务解决方案。是那些做起微服务很酷的开发者很危险。
微服务并不难，只需遵循12个要素，我们就可以完成并部署到dev，qa和prod docker和k8s。测试就可进行。
建议：当一个团队维护许多独立服务时，这是有问题的。当许多独立团队维护一项服务时，那也是错误的。因此，当这两中情况（不可避免地）成为现实时，需要怀疑：我们正确地划分了我们的服务吗？
微服务并非难事，分布式应用程序并非难事。我要说的是，如果您需要跟踪，那么您将遭受分布式系统工程的困扰，而不是微服务的痛苦。
我的想法：整体→SOA→微服务。根据域和优化需求进行分解，并使事情变得更细化。
这全都与粒度有关...如果我们确定正确的粒度，则Micro或macro都是无关紧要的。服务发现，断路器或网关服务，特定于服务的数据库隔离等都是必不可少的。
分布式整体是等待发生的FLP故障。
微服务最难的不是技术。这是因为他们需要实际的开发人员自治权才能做好，而大多数组织只是不想真正做到这一点。
真正的自治权要求每个团队复制很多东西：包括模式，商品组件，基础架构和工具。这并不便宜，并且使团队脱离了核心业务需求。通过dedup可节省资金，但会消除自主权并导致依赖。
按照这个定义，宏服务难道不是一堆通过共享代码在相对宽泛的范围内耦合的微服务吗？