当当网怎么从容器玩到微服务，云原生这条路其实没那么简单

（引用来源：2019年QCon北京站，张亮演讲《当当网云原生技术实践：从容器化到微服务》）

当当网,作为国内老牌的电商平台，很早就感受到了技术架构升级的紧迫性，他们的起点和很多传统企业一样，面临的是一个庞大的、已经运行了多年的单体应用，或者说是由多个“巨石”应用组成的系统，这种架构的缺点很明显，比如牵一发而动全身，一个小功能的改动可能需要整个大应用重新部署，发布周期长，风险高，而且资源利用率也不理想，用他们自己的话说，笨重”。

他们决定向云原生转型,这条路的第一步就是容器化，他们选择了Docker作为容器技术的基石，但容器化不是简单地把应用塞进集装箱就完事了，他们很快就遇到了挑战，首先是网络问题，传统的网络方案在容器这种动态创建和销毁的场景下不好用了，需要引入像Calico这样的容器网络解决方案来管理Pod之间的通信，其次是存储，有状态服务的数据怎么持久化？不能容器一删数据就没了，这需要对接分布式存储，最大的挑战可能是编排工具的选择，当时Docker Swarm、Mesos和Kubernetes都在竞争，他们最终选择了Kubernetes，但早期的K8s在生产环境的稳定性和易用性上也有很多坑要踩，当当网花了相当大的力气去定制和优化他们的Kubernetes集群，让它能符合自家业务的运维习惯和稳定性要求。

（引用来源：同上）

完成了基础设施的容器化,算是把“地基”打好了，接下来就是改造上面的“建筑”——也就是应用架构，核心就是拆分成微服务，微服务听起来很美，每个服务独立开发、独立部署、弹性伸缩，但做起来才知道里面的麻烦事更多。

当当网在微服务化的过程中,总结了几大难题，第一个是拆分策略，一个运行了多年的庞大系统，功能模块之间盘根错节，怎么拆？按业务领域拆？按功能模块拆？拆得太粗，效果不明显；拆得太细，运维和管理的复杂度会指数级上升，他们需要不断地梳理业务边界，这是一个非常考验架构设计能力的活儿。

第二个是分布式事务问题,在单体应用里，一个数据库事务就能搞定的事情，在微服务下变成了跨多个服务的分布式事务，下单扣库存、扣款、生成订单，这几个动作如果有一个失败，怎么保证数据的一致性？他们不得不引入TCC（尝试-确认-取消）等复杂的分布式事务方案，或者通过最终一致性来妥协，这都增加了开发的复杂性。

第三个是测试和排障,原来在一个应用里，调试和日志追踪都很直接，现在一个请求进来，可能像接力赛一样穿过十几个甚至几十个服务，任何一个环节出问题，整个请求就失败了，怎么快速定位是哪个服务慢了、哪个服务挂了？他们必须建立一套完整的监控、链路追踪和日志聚合系统，比如引入APM工具和ELK栈，这又是一笔巨大的基础设施投入。

（引用来源：技术社区对当当网案例的解读）

除了技术层面的挑战,还有组织和文化的挑战，微服务要求团队结构也随之改变，需要向“康威定律”所说的那样，按照服务边界来划分小团队，每个团队对自己服务的全生命周期负责（You build it, you run it），这对于传统的、按职能划分（开发、测试、运维分开）是一个巨大的变革，会涉及到流程重组和人员技能提升。

当当网的经历告诉我们,云原生这条路，真的不是简单地用上Docker和Kubernetes就万事大吉了，它是一个系统工程，涉及到基础设施升级、应用架构重构、开发流程变革和组织文化调整等多个维度，从把应用打包进容器，到让微服务在生产环境里稳定、高效地跑起来，中间有无数个坑要填，他们是一步一个脚印，解决了网络、存储、编排、服务治理、监控、事务等一系列具体而微的问题，才慢慢把这条路走通的，这个过程没有捷径，需要的是持续的技术投入、耐心的实践和不断的经验总结。