微服务架构在Netflix的应用：架构设计的经验教训在最近的一些博客里我们解释了采用四层的架构对于开发和部署微服务的应用程序是很重要的。如果你仍然采用十年前的开发流程和应用架构，你不能很快地获取和满足移动端用户的需求，移动端用户可以从越来越多的APP中进行选择。向微服务架构的转换给市场上的公司带来了很多的机会。对于系统架构和开发人员，它在为用户提供新的用户体验的同时又带来了一种前所未有的控制力和速度。但在现在这样紧张的节骨眼上，感觉上是不允许出一点差错的。现实世界中，你不可能革新期间就停止APP的开发和部署的。你深深明白未来的成功取决于能否成功迁移到微服务架构中来，但是你该怎么来做呢？Netflix_Logo_Digital+Video幸运的是，微服务的早期实践者本着开源的精神慷慨地分享他们的专业知识，不仅有开源代码，也会在会议上做一些演讲，写一些博客。Netflix就是其中之一。AdrianCockcroft作为web工程和云计算架构师总监负责监督了公司内负责DVD租赁系统的100人的工程师团队从传统开发模式到只需要很少人员负责数百个后台服务的微服务架构来为数百万的Nrtflix客户提供数字娱乐服务。BatteryVentures公司的技术人员Cockcroft是微服务和云架构方面著名的布道者，目前供职于Nginx技术咨询委员会。后续的两篇文章中，我们会给大家将一些从去年Cockcroft做的2场演讲，一场是10月的NGINX大会上，一场是几个月之后的硅谷微服务meetup中的一些启发。这篇里面主要是给微服务架构一个定义，阐述了一些设计微服务架构的最佳实践后面的一篇讨论了采用软件设计新思路以及绕着这种新思路来重组团队的原因和方式。什么是微服务架构?Cockcroft把微服务架构定义为由松耦合的有相应语境的元素构成的一种面向服务的架构松耦合意味着你可以独立更新这些服务。更新其中一个服务并不会改变其他的服务。如果你的系统里有大量的特殊服务，但是又必须同时更新它们，它们又不是微服务，因为它们不是松耦合的。在向微服务迁移的时候人们常常会把数据库的耦合看的过重，也就是所有服务都连的是同一个数据库，更新其中一个服务就意味着要改变数据库的schema。这种情况你需要对数据库进行拆分boundedcontexts的概念来源于EricEvans的书DomainDrivenDesign。就软件开发的目的而言，拥有恰当语境的微服务本身是自包含的。由于微服务和其他微服务之间交互是严格通过API来进行的，你不需要共享数据结构、数据库表结构和对象的内部表达形式，在不了解...
