3．篇后语

本文所提倡的微服务，是结合作者所在团队自身业务特点来说的，适合自身的场景，是建立在团队人员素质到了，有成熟的基础设施和框架、中间件辅助，流程也规范，包括CI、敏捷等，团队都做好了准确去做这个转变，有足够的能力来实施，微服务化也就是水到渠成的事了。相反，小团队在前期或者野蛮生长时期，不宜选择微服务，不但影响效率还带来额外的复杂度。成长型或者大公司，有成熟的流程、规范、基础设施、平台等，要想在整条交付链路上加速，就需要投入更多的资源保障微服务化，一切自动化了，能治理了，回头看来这一切就都是值得的，远期收益非常可观。

最后要说的是，架构只是标准、骨骼，对微服务的讨论不应该让我们忘记了更重要的问题，驱动软件项目成功和失败的重要因素。软因素如团队中人的素质，以及他们如何彼此合作、沟通，这都会对是否使用微服务有很大的影响。在纯技术层面上来讲，应该把重点放在干净的代码、完善到位的测试，并持续关注架构的演化进步，这才是一个软件工程师的根本职责。