微服务给我们带来的并非只有好处，还有相应的一些挑战。
服务“微”化之后，一个显著的特点就是服务的数量增多了。如果将软件开发和交付也作为一种生产模式看待，那么数量众多的微服务实际上就类似于传统生产线上的产品，而在传统生产模型下，为了能够高效地生产大量产品，通常采用的就是标准化生产。
比如在汽车产业，在福特 T 型车没有出来之前，大多汽车企业的生产效率都不高，而福特在引入标准化生产线之后，福特 T 型车得以大量生产并以低成本优势快速普及。
在其他行业也是同样的道理，个性化生产虽然会深得个别用户的喜欢，但生产成本通常也会很高，生产效率因为受限于个性化需求，也无法从“熟能生巧”中获益，所以，最终用户需要为生产成本和效率付出更多的溢价才能获得最终产品。
而相对于个性化生产来说，标准化生产走的是另一条路，通过生产标准产品，使得整条生产链路可重复，从而提升了生产效率，可以为更广层面的用户提供大量“物美价廉”的标准产品。
微服务的研发和交付其实就类似于产品的生产链路，而数量大这一特点则决定了，我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系。
虽然微服务化之后，我们可以投入相应的人力和团队对应各个微服务的开发和交付，可扩展性上绝对没有问题，但这不意味着现实情况下我们就能这样做，因为这些都涉及人力和资源成本，而这往往是受限的。所以，使用标准化的思路来开发和交付微服务就变成了自然而然的选择：
通过标准化，我们可以重复使用开发阶段打造的一系列环境和工具支持。
通过标准化，我们可以复用支持整个微服务交付链路的各项基础设施。
通过标准化，我们可以减少采购差异导致的成本上升，同时更加高效地利用硬件资源。
通过标准化，我们可以用标准的协议和格式来治理和维护数量庞大的微服务。
如果你还对使用标准化的思路来构建微服务体系存有疑惑，那么，不妨再结合微服务的多语言生态特性思考一番：
增加一种语言生态用于微服务的开发和交付，我们是否要围绕着这种语言生态和微服务的需求重新搭建一套研发/测试环境？
我们是否还要围绕着这种语言生态打造一系列的工具来提升日常开发的效率？
增加一种语言生态，我们是不是还要围绕这种语言生态搭建一套针对微服务的交付链路基础设施？
增加一种语言生态，我们是否还要围绕它提供特定的硬件环境以及运维支撑工具和平台？
多语言生态虽然灵活度高了，不同语种和思路的团队成员也能够百花齐放了，但是不是也同样带来了以上一系列的成本？
所以，很多事情你能做，并不意味着你一定要做。适度的收缩语言生态的选择范围，并围绕主要的语言生态构建一套标准化的微服务交付体系，或许是更为合理的做法。
要实施高效可重复的标准化微服务生产，我们需要有类似传统行业生产线的基础设施。否则，高效可重复的开发和交付大量的微服务就无从谈起，所以，完备的微服务研发和交付体系基础设施建设就成为了实施微服务的终极挑战。
一个公司或者组织要很好地或者说成熟地实施微服务化战略，为交付链路提供完备支撑的基础设施建设必不可少！
