5微服务的关键不在于“微”而在于“合适的巨细”
每当这样做的时候我都冒着引入新 bug 和破坏用户体验的风险。
5微服务的关键不在于“微”而在于“合适的巨细”
每当这样做的时候我都冒着引入新 bug 和破坏用户体验的风险。将微服务合并成单体架构的历程中虽然有时候很令人兴奋但总体还是令人感应恐惧的而且需要大师级的计划、风险控制和测试。
再次强调一遍如果它不值得做的话我就不会做了。
7微服务也有纯经济方面的成本
自 8 年前建立以来InVision] 一直都是一个单体系统其时只有3 个工程师。
随着公司的发展和生长系统的数量险些没有增加可是工程团队的规模却在快速扩张。几年的时间我们有了几十名工程师包罗前端和后端他们在同一个代码库上开展事情所有的部署都市到同一个服务行列中。
在所有关于为什么说独立服务是一件“好事”的理由中这个理由经常被提及可是在我（有限的履历）看来这通常是不建立的。
除非某项功效是 CPU 麋集、IO 麋集 或 内存麋集 的否则独立的可扩展性可能并不是你需要担忧的“能力”。许多时候你的服务器都在等着做事情为一个应用法式添加“更多的 HTTP 路由处置惩罚法式”并不会突然耗尽它所有的资源。
这里的看法在于解决方案是围绕团队结构（和团队通信开销）举行“优化”的而纷歧定是为相识决特定的技术或性能问题。
6大多数技术并不需要“独立扩展”
对我的团队来说“合适的巨细”意味着更少的代码堆栈更少的部署行列更少的语言以及更少的运维仪表盘。对于这个很是小的团队来说“合适的巨细”更多的是关于“人”而不是关于“技术”。所以就像 InVision 最初引入微服务是解决“人的问题”一样我们团队现在摧毁这些微服务也是为相识决“人的问题”。
简而言之康威定律为组织带来的所有收益随着时间的推移都酿成“遗留”团队的欠债。所以我们一直在努力“调整”责任域让平衡回归康威定律。
或者换句话说我们在实验改变服务界限以匹配团队的界限。这意味着将微服务重新合并为单体架构。
我将服务重新合并成单体并不意味着要将微服务从生活中彻底驱赶出去。这个任务的目的是 “调整”单体的巨细。这样做是为相识决团队的痛点。
如果不能淘汰冲突那么我就不会花费 那么多的时间（和时机成本）来提升、转移和重构旧的代码。
支撑建立独立服务的论据之一就是这些服务是可以“独立扩展”的。也就是说可以更有针对性地提供服务器和数据库以满足服务的需求。因此与其建立大型的服务却只扩展其中一部门功效我们能够在独立扩展其他服务的同时让某些服务保持规模很小的状态。
2微服务解决了技术和人的问题
为了明白我为何要销毁一些微服务首先很重要的一点就是要明白为什么一开始要建立这些微服务。
微服务解决的是两种类型的问题也就是 技术的问题和 人的问题。
技术的问题在于应用法式的某个方面给基础设施带来了过重肩负这反过来又很可能会导致糟糕的用户体验（UX）。例如图像处置惩罚需要大量的 CPU。
如果 CPU 的负载变得很是高这将会导致应用其他处置惩罚资源的饿死现象。这会影响系统的延迟。而且如果更糟糕的话那么这会影响系统的可用性。
另一方面 人的问题与应用的关系并不大它关系到你会如何组织团队。
在应用法式的特定部门投入事情的人越多开发和部署就会越慢而且越容易堕落。例如如果你有 30 个工程师都在竞争“连续部署（CD）”同一个服务就会泛起许多排队的现象这意味着许多本可以交付产物的工程师只能坐等轮到他们举行部署。
该定律通常以“编译器”为样例举行说明：
多年来InVis。