天下武功，唯“快”不破。在当下互联网环境下，相信每一个 IT从业者都能够深切地体会到“快”这个字对应用开发的影响。互联网产品的需求来得快，变得快，你的产品必须持续创新，不断给用户带来新的价值，否则用户会毫不犹豫弃你而去。用户期望的交付周期也极大缩短了，导致传统以月为单位的交付周期不得不被压缩到天甚至小时，这就要求互联网产品必须小步快跑，快速迭代，总之，就是要“快”。
很多互联网公司都知道做互联网要“快”，但是现实情况是他们中的大部分都面临着产品迭代速度越来越慢的问题。分析原因可以发现一个共同点，就是随着产品功能的累积，应用实现越来越复杂，代码规模越来越大，开发团队工作在一个逻辑复杂、模块耦合的单块架构应用之上，从而导致应用难于维护和更新，发布过程很长，而且随时面临发布失败的风险。微服务架构就能够很好地解决这个问题。微服务架构自 2010年开始逐渐被大家熟知，通过对传统单块应用进行服务化切分，把一个大而复杂的问题化解为多个小而简单的问题，服务之间通过契约来约定依赖，做到服务独立发布和演进。今天，微服务架构已经被广泛运用在像 Google、 Facebook这样的大型互联网公司，为他们的快速交付和持续创新提供软件架构支撑。
微服务的出现，为运维又打开了一扇窗。微服务将整个业务系统拆分为相对独立的业务模块，并强调各个微服务都可以独立测试、独立部署、独立运行；微服务之间是一种真正的低耦合，就像汽车的各个零部件，哪个坏了，拆掉换个新的就能组装上；微服务面向产品而不是项目，这样，开发、测试、运维（系统、 DBA等）可形成更稳定的“小”团队，而不是项目周期一到，各个职能解散，各回各家；微服务配以 Docker，更可谓珠联璧合。这些都对运维提出了新的机遇和挑战，熟悉 DevOps、懂 Docker、沟通能力强的综合型运维人员，市场需求和价值更加突显。
微服务的概念初看简单清晰、容易理解，但在企业中的实际实施其实是一件很困难的事情。尤其很多计划实施微服务的公司在服务划分、 DevOps和相应的组织结构变化方面毫无经验，付出了实施的代价，却很难真正享受到微服务带来的好处。《微服务架构与实践》总结了在真实大型软件系统上实施微服务的经验和心得，具体指导了微服务实施在技术方面的实践，非常值得参考。
