为应对如今无线优先和全渠道用户体验的需求和挑战，我们该如何设计灵活的面向体验的微服务架构？它有哪些模式和最佳实践？携程，Netflix和SoundCloud这些知名互联网公司是如何实践面向体验的微服务架构的？在过去的2015年，大牛马丁福勒对微服务有哪些新的观点？
微服务各家玩法不尽相同，我发现一些术语的叫法各公司也是不同的，可以说微服务目前仍在激烈的演化中，这个领域还未成熟和标准化，所以今天的分享主要是我个人的视角和总结，目的是抛砖引玉，激发大家进一步探索和实践。
本次分享的主题包括：
微服务架构原理
用户体验适配层（Backend For Frontend）
携程无线微服务案例分享
Netflix微服务架构分析
SoundCloud微服务架构分析
微服务架构不是免费的午餐
总结
本次分享也是应架构群内一些朋友的要求，将之前零散分享的内容总结成文，本次分享过程中会贴出相关内容参考链接（其中有些来自SlideShare和Netflix techblog的链接需要FQ访问），供有兴趣的朋友进一步学习。
一、微服务架构原理
微服务是个新概念，但它没有一个明确的定义，各家对微服务的描述不尽相同，本人更倾向于用一些架构原理来描述它，因为架构原理是相对抽象和稳定的，而具体实现可以千差万别。微服务原理和软件工程，面向对象设计中的基本原理相通，体现如下：
单一职责（Single Responsibility），一个服务应当承担尽可能单一的职责，服务应基于有界的上下文（bounded context，通常是边界清晰的业务领域）构建，服务理想应当只有一个变更的理由（类似Robert C. Martin讲的：A class should have only one reason to change），当一个服务承担过多职责，就会产生各种耦合性问题，需要进一步拆分使其尽可能职责单一化。
关注分离（Separation of Concerns），跨横切面逻辑，例如日志分析、监控、限流、安全等等，尽可能与具体的业务逻辑相互分离，让开发人员能专注于业务逻辑的开发，减轻他们的思考负担，这个也是有界上下文（bounded context）的一个体现。
模块化（Modularity）和分而治之（Divide & Conquer），这个是解决复杂性问题的一般性方法，将大问题（如单块架构）大而化小（模块化和微服务化），然后分而治之。
微服务架构同时还是一个组织原理的体现，这个原理就是康威定律（Conway’s Law），Melvin Conway在1968年指出：“Any organization that design a system(defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”，翻译成中文就是：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。Dan North对此还补充说：“Those system then constrain the options for organization change”，简言之，这些系统在建成之后反过来还会约束和限制组织的改变。下面两个图进一步解释了这一组织原理：