微服务架构在企业内的应用问题探讨（二）

作者：shawn

前情提要

上期我们已初步了解了微服务的概念并讨论了微服务应用的热点问题（Q1-Q2），戳我复习。本期我们将继续和大家讨论微服务应用问题（Q3-Q5）。

03 开发版本控制托管平台缺乏可见性

某家中等规模的企业进行了内部IT系统的微服务改造已经一年多了，他们使用的是 Gitlab 版本控制平台，版本控制系统中有 1000 多个仓库，他们有 5 个内部系统，每个内部系统都由多个微服务组成。他们的架构师不得不花一天时间弄清楚系统A和B的仓库对应的到底是哪些服务，以及各自代码库是哪些协同的一部分。

后来他们通过开发阶段就对微服务进行分组编排和管理的方式来解决这个问题（ Github 并没有组功能，只能使用主题或命名约定来变通实现它）。但很明显，这也给项目经理和配置管理的人员带来了很大的工作量，对于一个敏捷的企业内部IT团队，不太可能“奢侈”的拥有这类专职岗位。

04 服务如何拆分治理、如何和业务关联难以有明确规范的定义

企业IT团队如果经验不足，一般并不知道什么应该被视为服务。关于究竟是什么构成一个单一的微服务，人们对此存在很多混淆的认识和困惑的概念。
让我们举一个例子，假设你的应用程序具有类似插件的架构，在这个架构中，你集成了多个第三方服务。那么每个集成应该是一个微服务吗？

我看到很多团队，都在为每个集成创建一个微服务。随着集成数量的增加，这种情况很快就会失控，以至于无法管理。这些服务通常太小，以至于将它们作为单独的进程运行，会增加更多的开销。我们认为，哪怕只拥有少量的大型服务，总比提供太多的小型服务要好得多。

我将从创建一个服务开始，对业务组织中的整个部门进行建模。这也符合 DDD（领域驱动设计， Domain Driven Design）设计方法体系。我将一个域分为子域和有界上下文。有界上下文表示公司内部的一个部门，如财务部门和营销部门。
你可能在想，这不是会导致大型服务的出现吗？
没错，但是以我的经验来看，将整体重构为微服务总之比反之更容易。随着你的知识经验越来越多，你可以转向代表更小问题的细粒度微服务。你可以应用单一责任原则（Single Responsibility Principle）来了解你的微服务是否变得过大，做的事情是否过多。

然后，你可以将它分解成更小的独立服务。任何服务都不应该直接与其他服务的数据库通信。他们应该只通过已发布的合同进行沟通。而相同类型有上下文依赖的服务，最好需要限制在服务通信上，而服务通信是微服务系统性能低下的首要原因。如果两条信息相互依赖，那么它们应该属于同一个服务器。换句话说，服务的自然边界应该是其数据的自然边界。

05 代码重用策略不明确

一些“短平快”的项目往往需要将部分通用的微服务复制到多个与特定问题相关的应用中。因此，如果在该代码中发现 bug 的话，就需要将其修复应用到所有地方。但这种项目一般开发时间都很紧张，也很难有充足的测试资源。在时间紧迫的情况下，我们可能无法将更改应用于全部服务。这并非说开发团队不懂做正确的事情。实际上，在组织结构内，人们总是默认采用简单且容易出错的做事方式。

正确的方法是，使用像 Bintray 或 Nexus 这样的工件管理器，并在那里发布依赖项。然后，每个微服务都应该依赖于这个库。你需要构建工具，以便在发布新版本的库时，所有的微服务都应该进行更新和重新部署。

使用微服务并不意味着你要放弃当下对我们有用的最佳实践。我们需要对很多工具进行使用和投入，这使微服务的升级变得更容易。但各种各样的工具会带来更多的学习成本，对团队的开发人员的能力复合要求更高，我们不能期望每一位开发人员都具备中高级架构师的知识面和技术水准。

但在没有适合的工具和自动化的情况下，使用微服务会导致灾难。所以，我们要根据实际情况进行合理规划。