微服务会为企业带来诸多好处，比如：
在微服务架构的应用中添加新的feature，不需要重写整个应用；
更小的代码库维护起来更简单也更快捷，节省了开发成本和时间，从而提高了生产效率；
应用的各个模块可以分别扩展，而且更容易部署。
本文通过沃尔玛，Spotify和Amazon等创新企业的经验，带你了解使用微服务的最佳实践，好处和痛点。
微服务架构如何拯救沃尔玛？
当企业陈旧的架构开始对其业务产生负面影响时，企业应该做什么呢？
这是一个数百万美元的问题，在加拿大沃尔玛连续两年的黑色星期五都没能为顾客提供良好服务之后，这也成为了其IT部门必须要解决的问题。Kevin Webber帮助沃尔玛重新设计了线上零售业务的架构。
『旧的架构已经不能支撑每分钟600万的PV量，也不可能提供好的用户体验。』
在拥抱微服务之前，Walmart的架构还是2005年的互联网架构，单体架构。公司从2012年开始就决定重新设计这个系统，因为其已经不能支撑每分钟600万的PV，而且每逢大型购物节必挂。他们希望新的架构能够到2020年依然适用，支撑40亿用户，2500万的移动用户，每人5200G的数据。
为了在合理的花费下，达到近乎100%的可用性，沃尔玛采用了微服务架构。
『系统拥有足够的弹性去处理峰值，同时不产生负面的用户体验，是非常重要的。』
微服务架构为沃尔玛的业务带来了极大的提升：
转化率在一夜之间提升了20%；
移动端的订单立即增长了98%；
架构改变之后，黑色星期五或节礼日（加拿大的黑色星期五）等大型购物节期间，再没有出现过宕机。
运维成本的降低也是很重要的，因为公司将昂贵的硬件换成了便宜的X86服务器。节省了40%的计算资源，总成本下降了20-50%。
『微服务架构并不是单纯的对技术创新的追求，是我们能在市场保持领先的关键因素。』
Spotify靠微服务实现完美用户体验
Spotify是全球最大的正版流媒体音乐服务平台，其工程VP Kevin Goldsmith认为，一个企业想要在激烈竞争的市场中，保持快速发展和持续创新，需要一个可扩展的架构。
Spotify每个月要服务7500万的用户，平均每次服务时长在23分钟，同时后台运行相当复杂的业务，还要紧盯着竞争对手Apple和Google。
『如果你担心系统不能应对用户的激增，就将你的系统构建为相互独立的组件。』
为了避免组织内的synchronization hell，Spotify的微服务架构是由一个自治的全栈团队负责的。
『问题在于，如果你想要在单体结构的系统中添加一个新的feature，客户端团队需要向核心团队要到API和权限；核心团队要向服务器团队提需求去实现所需要的功能；服务器团队又要让基础设施团队新建一个database，这其中产生了很多沟通成本。』
Spotify有90个团队，600个开发者，这些散布在2大洲的5个开发部门要协作去开发这个产品，所以需要将这些依赖最小化。
这也是Spotify启用全栈团队的原因，每个团队都有后端开发，前端开发，测试，一个UI设计和一个产品负责人。这些团队是自治的，而且各个团队的职责是完全独立，没有交叉的。
『开发者部署自己的服务，并且运维自己所负责的模块。这意味着，如果他们代码没写好，一旦出了问题也要负责加班加点地修复，修复得也很快。』
Spotify的微服务是一个松耦合的架构，在独立的组件之间没有严格的依赖。
Kevin提到了构建微服务的主要挑战：
因为上千个实例在同时运行，所以很难监控；
微服务容易导致延迟：Spotify要调用多个服务，这些服务又在调用其它服务，这些调用过程都会产生延迟。
容器所提供的轻量级、面向应用的虚拟化运行环境为微服务提供了理想的载体。同样，基于容器技术的云服务将极大的简化容器化微服务创建、集成、部署、运维的整个流程，从而推动微服务在云端的大规模实践。详情请点击『基于容器云的微服务架构实践』。
但是，微服务架构为企业带来的好处也是显而易见的：
很容易根据瓶颈去扩展：可以找到整个系统的瓶颈，从而有针对性地扩展或修复，避免了大量的重写；
更容易测试：测试平面更小了，开发者能在本地测试服务，不必非要部署在测试环境中；
更容易部署：应用更小，部署很快；
在某些情况下更容易监控：每个服务的功能更少了，监控起来更容易；
服务可以被独立地标注版本：没有必要在同一个实例中添加多个版本的支持，所以他们没有添加多个版本到同一个二进制中；
面对重大故障，微服务所受的影响更小；
采用微服务架构之后，即使有大量的服务同时宕掉，Spotify的用户可能也察觉不到。系统拥有更强大的容错能力，每个可能出错的服务都不会承担过多的功能，所以不会影响Spotify的使用。
对于还在犹豫要不要拥抱微服务的企业，Goldsmith给出的建议是：
『我们使用微服务几年的时间里，一直保持着相当好的扩展。我们有成千上万个运行的实例，并且可以根据意愿重写这些服务，而不只是修改或添加新的数据。只要服务达到扩展的拐点，我们就会重写这个服务，这对于微服务架构真的很简单。所以当你们想要在公司推进微服务时，就让他们看看Spotify，看看Netflix这些例子，然后告诉他们：这都是微服务的实践案例，而且他们用得很满意。』
Amazon拥抱DevOps哲学
AWS资深产品经理Rob Birgham分享过Amazon是如何拥抱DevOps哲学并迁移到微服务基础设施的。
2001年，Amzon.com的零售网站是一个大型的单体，多层结构，每层都有多个组件，但是耦合度很高，运行起来就像一个整体。
『许多初创和企业项目开始时都采用这种架构，因为这种方式起步很快，但是随着项目的成熟和开发者的增多，代码库会变得越来越庞大，架构也会变得越来越复杂，单体架构会带来额外的开销，软件开发周期也会变慢。』
Amazon有大量的开发者服务于一个大的单体架构的网站，尽管每个开发者只负责那个应用中的一小块，一旦有更新，也还是要在与项目中其它模块的协调中花费大量精力。
而添加新feature或修改bug时，还需要确保这些更新不会打断其他人的工作；如果要更新一个共享的库，需要通知每个人去升级这个库；如果要进行一个快速修复，不仅要协调自己的时间，还要协调所有的开发者。
『这使得一些需求更新就像merge Friday或merge week一样紧张——所有开发者的更新集合到一个版本中，要解决所有的冲突，最终生成一个master版本，推送到生产环境中。』
即使每次的更新规模很大，依然给交付环节带来了很大的开销，整个新的代码库需要被重新构建，所有的测试用例需要重新运行，最终要将整个应用部署到生产环境中。
在2000年左右，Amazon甚至有一个团队专门负责将应用的最新版本，手工部署到生产环境中。
对于软件工程师来说这很令人沮丧，最重要的是软件开发周期变得很慢，创新能力也减弱了，所以他们进行了架构和组织的重大变革。
这些变化开始于架构级别：Amazon从单体架构迁移到了面向服务的架构。
『我们将所有代码按照功能模块分隔，然后将每个模块用网络服务接口封装。各个模块间的通信必须通过这些web service API。』
这样Amazon就建造了一个高度解耦的架构，这些服务可以相互独立地迭代，只要这些服务符合标准的网络服务接口。
『那时这种架构还没有名字，现在我们叫它微服务架构。』
Amazon将这些改变也应用到了组织架构中，他们将中心化的，层级的产品开发团队，打散成了小的『two-pizza teams』。
『最初我们希望每个团队控制在两个披萨就能喂饱的规模，实际上现在每个团队有6-8个人开发者。』
每个团队都对一个或几个微服务有绝对的控制权，在Amazon这意味着：要和顾客对话（内部和外部的），定义自己的feature roamap，设计并实现这些feature，测试这些feature，最后部署和运维这些feature。
如果在整个过程中的任何地方出了问题，这个小团队有责任去修复它。任何人的偷懒或者犯错都要自己承担责任，甚至在半夜加班修复这些服务。因此工程师团队有极大的动力去保证整个产品周期的高速运转。
『那时对这种团队，业界还没有统一的名称，现在叫DevOps。我们负责开发，测试，运维并将所有服务merge到一个工程团队中。』
在经过架构和组织的重大变革后，Amazon极大地提高了前端开发的效率。产品团队可以很快地做决定，然后转化为微服务中的新feature。现在Amazon每年要进行5000万次部署，这都多亏了微服务架构和他们的持续交付流程。
『其它企业该如何做到？具体情况要具体分析，需要看一个公司的文化，组织和流程等各方面。并且每个DevOps变革都会需要的基础是：一个高效，可信赖的持续交付流程。』