采用微服务架构之前要问的3个问题

麦迪逊·弗里德曼（Madison Friedman）是美国Vertex Ventures的投资实习生，也是沃顿商学院的MBA候选人。

我今年夏天在Vertex Ventures US工作，这是我进行测试的机会。在采访了来自Facebook，Fannie Mae，Confluent，Salesforce等各种公司的30多位行业专家之后，与PagerDuty，LaunchDarkly和OpsLevel的联合创始人举办了网络研讨会，我们能够回答三个主要问题：

在与我们交谈的数十家公司中，只有两家尚未开始微服务之旅，但两家公司都在积极考虑。行业趋势也反映了这一点。在O’Reilly对1500多个受访者的调查中，超过75％的人开始采用微服务。

公司很少从头开始使用微服务进行构建。在与我们交谈的公司中，只有一家这样做。一些启动公司（例如LaunchDarkly）计划使用微服务构建其基础架构，但一旦意识到高昂的开销成本，便开始采用整体式服务。

“与实际构建我们自己的服务相比，我们花费更多的时间有效地为分布式系统构建和运行系统，因此我们退缩了，” LaunchDarkly的首席技术官兼联合创始人John Kodumal说。

他说：“例如，我们试图在中层空间做的事情是不可能的。” “我们无法进行任何日志记录。零停机时间部署是不可能的。基础架构中有很多错误，我们花了很多时间调试基本的东西，我们没有建立自己的服务。”

因此，对于公司来说，从整体开始，然后转向微服务，以随组织扩展其基础架构，这种情况更为普遍。当一家公司拥有约30个开发人员时，大多数公司开始通过转移到微服务架构来分散控制权。

具有完整整体的大型公司热衷于转向微服务，但成本高昂，过渡可能需要数年。 Atlassian的平台基础架构位于微服务中，但是尽管正在进行不断的分解工作，但Jira和Confluence中的遗留巨石仍然存在。大型公司通常会陷入这种过渡。但是，强大的，自上而下的策略与自下而上的开发团队支持相结合，可以帮助房地美等公司取得实质性进展。

一些初创公司，例如Instacart，首先转移到模块化的整体平台，该模块允许代码驻留在单个存储库中，同时开始将离散代码功能的所有权分配给相关团队的过程。这使他们能够通过平衡具有集中式存储库和发布管道的可见性以及对部分代码库进行离散所有权的灵活性来减轻与微服务体系结构相关的开销。

团队可能会采用不同的路线来建立微服务架构，但是一旦到达那里，他们往往会面临一系列共同的挑战。 OpsLevel首席执行官兼联合创始人约翰·拉班（John Laban）帮助团队构建和管理微服务，他告诉我们：“借助基于分布式或微服务的架构，您的团队可以从彼此独立的移动中受益，但是需要注意一些陷阱对于。”

确实，链接的O'Reilly图表显示了25％以上的受访者分享了采用微服务时组织面临的十大挑战。当我们讨论了上面的一些采用障碍时，我们的采访反馈突出了有关管理复杂性的问题。

缺乏对服务的一致定义会导致团队通过创建过多的相似服务或将相关服务分布在不同的组中而产生不必要的开销。我们与之交谈的一家公司彻底分解了他们的整体，走得太远了。他们的服务定义太狭窄，到分解完成时，他们剩下4,000多个微服务来管理。然后，他们不得不回溯并整合到一个更易于管理的数字。

定义太多服务会导致不必要的组织和技术孤岛，同时增加复杂性和开销。每个服务上都必须存在日志记录和监视，但是由于所有权分散在不同的团队中，缺乏标准化的工具可能会引起可观察性的麻烦。对于团队来说，要获得跨整个体系结构的太多不同的交互系统和服务来获得单一视图是一项挑战。