可能有人会不以为然：微服务不是技术架构吗？我们自己的系统就正在微服务化呢！
不要急，我们慢慢聊。
2016 年，“微服务体系建设”几乎成为了各家架构师们宣讲必备的技术热点。现在回头来看，这一年其实正是容器集群编排与管理集中爆发的一年，而容器，这个可以把应用程序完整封装起来的技术实现，恰如其分地描绘出了一个看得见摸得着的运行单位。相比以前焦头烂额也解释不明白的“服务”两个字，一个敲敲命令行就可以执行起来的容器镜像实在是“天地良心”。
很多组织都公开宣讲过自己的微服务架构实践和落地经验，其中十有八九都能归结于容器化架构的实施和上线。也难怪一些老牌的微服务架构的先驱（比如 Netflix 和 Pivotal）纷纷表示摸不着头脑：咱前好几年费老鼻子劲折腾出来的微服务体系，真就这么被一家容器创业公司给实现了？
其实，微服务架构之所以能够被现在的架构师们所逐渐接纳，成体系的服务编排与管理理论的成型和落地确实是背后最值得关注的推动力量。有趣的是，这套理论本身成型已经多年，而能够真正落地，还真是多亏了容器技术这趟“东风”。在此之前，Spring 框架通过依赖注入和切面编程，对应用程序强制灌输良好的架构规范和配置标准几乎是我们能接触到的唯一的微服务落地手段。而且这套标准的强制力在应用的开发周期结束后就戛然而止了，只有在容器技术成熟之后，微服务理念才得以扩展到了运维的范畴，再加上 Google Kubernetes 等集群管理项目的推波助澜，各种各样的微服务落地实践才得以应运而生。得益于这些开源容器集群管理技术的繁荣，当我们再谈起微服务，诸如服务注册、发现、负载均衡、服务容错和健康检查等一系列以往只出现在 Borg、Netflix 基础设施里的核心理念，我们国内的技术人员们也能信手拈来了。
容器技术确实从头到脚改变了微服务理念的落地方式，我们现在的架构师们也已经习惯于在技术分享时用“微服务”来代替以前的“应用”、“Tomcat”，但这远远不够。我们必须认识到，将 Tomcat 放进容器里运行绝对不可能修正一个拙劣的架构设计；反过来，优秀的架构师分离出来的实现单位也完全不需要容器的包装就能满足单一职责和高可扩展的要求。容器技术在微服务体系里的本质作用是提供了微服务单元部署的便利性，而微服务思想的实现则必须依赖于从设计初始就贯彻在程序中的良好的“变成言行”。这些言行包括了小到变量命名和代码规范的制定，大到系统接口的设计和分布式协调的选型，都缺一不可。这也是为什么我们没必要把微服务和容器技术绑定起来，因为在贯彻微服务理念的能力上，容器技术恐怕还不如一套 Spring 框架来的有效。归根到底，容器只能为我们提供实施微服务的形体，而这个形体的灵魂，却只能扎根于我们每个技术人的头脑中。
有位 Google 的资深工程师曾经这么说过：“我不理解你们所谈论的微服务，因为我认为程序本来就应该是那么设计的”。微服务的思想本身并不玄妙，它更像是一种文化，生长在每个技术团队当中，潜移默化地影响着我们的技术和产品。在这个圈子里，有太多的微服务实践能够让我们学习和模仿，但一位有着良好编程习惯的技术人员恐怕才是解决这个问题的关键。
2016 年，容器技术的繁荣推动了微服务架构风格的第二次普及，却不应该掩盖容器技术本身在良好系统设计规范中的无能为力。在新的一年，相比继续执着于各种酷炫的微服务架构建设和推广，我们不妨尝试去向优秀的开源社区学习强制而高效的 Code Review 和 CI 体系，借此培养技术人员良好的“编程言行”，这恐怕能够让我们在系统架构优化的不懈努力中，取得事半功倍的效果。
张磊，HyperHQ 项目成员，Kubernetes 项目 PM 和 Feature Maintainer
目录
热点 | Hot
OpenAPI 规范 3.0 版接近最终发布
独家盘点：春节期间你可能错过的 IT 技术大事件
推荐文章 | Article
谈谈技术选型
2016 年 JavaScript 领域中最受欢迎的“明星”们
服务拆分与架构演进
观点 | Opinion
左耳朵耗子：我对 GitLab 误删除数据库事件的几点思考
评论