在组织全面拥抱微服务以后，随着组织内的团队规模越来越大，其中的每一个团队都很可能开始专注于一组特定的编程语言和工具。即便使用同样的编程语言，不同团队也会在实现同一个目标时选择不同的工具组合。尽管这并没有错，但是这会导致开发者换到其他团队的难度增大。创建新服务的习惯以及代码结构会有很大差异。
严格规定团队能够使用的工具和编程语言，并强制不同团队采用同一套标准方式来创建服务，会损害团队的工作效率和创新能力，最终导致所有问题都采用同样的工具。幸运的是，可以让团队在为服务自由选择编程语言的同时遵循一些通用的实践方案。可以针对所使用的每种语言封装一套工具集，同时确保工程师能够访问那些能够方便各个团队遵守实践的资源。
开发者应该以相同的格式将日志集中保存到同一个地方，像断路器、功能标志的功能以及共用相同的事件总线的能力也应该是现成可用的。团队不仅可以做出选择，还可以保证运行服务的基础设施保持一致。这些工具就组成了服务底座。可以在服务底座的基础之上构建新的服务，而不需要做太多的前期调查和准备工作。
接下来，要思考下如何为服务构建一套底座——将普遍关注的内容和架构选型抽象化，同时还能够加快团队启动新服务的速度。
不管使用哪种开发语言，都有很多选项，所以挑选组件所花费的时间会越来越长，同时还要冒着选出来的类库不够理想的风险。一个组织很有可能根据它们所需要解决的问题来使用两到三种语言作为主要语言。因此，使用同一种语言团队是会同时存在的。一旦某个团队在某些类库上获得了一些经验，为什么不将这些经验造福于其他团队呢？可以提供一套已经应用于生产环境的类库和工具集合，这样，开发者在开发新服务时直接从这些类库和工具中进行选择，而无须通过深入了解和挖掘每个类库的功能和特点来权衡它们的优缺点。
为了简化团队创建服务的工作，花些时间来为组织内构建和维护服务所使用的每种语言提供一套基本框架和经过审查的工具是很值得的。开发者同样应该确保这个框架遵循了可观测性标准以及对基础设施相关代码的抽象。同样这个框架应该能够反映对服务通信方式的架构选型，比如，如果组织倾向于服务间采用异步通信，那么就要提供现有的事件总线基础设施所必需的类库。
微服务底座框架能够让团队选择一个技术栈（语言+类库）并快速搭建起一个服务，其目的是简化服务的创建过程，同时确保开发者拥有一套所有服务都要遵循的标准，而不管哪个团队负责相应的服务。
提供微服务底座能够降低开发者所面对的风险，这是因为微服务底座能够降低开发者所选择的语言和类库组合并不适用于特定需求的可能性。
此外对于测试也很重要，测试分层时可以把微服务底座部分放到一层，统一测试而不是每个服务都去重复测试。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论