“ 微服务，近来热度十足的名词。作为一个新概念，它还没有一个明确的定义。究竟什么是微服务，微服务又有何与众不同？不妨听听本文作者的“老司机一家之言”，欢迎在评论区讨论交流。
微服务架构原理
微服务是个新概念，但它没有一个明确的定义，各家对微服务的描述不尽相同，本人更倾向于用一些架构原理来描述它，因为架构原理是相对抽象和稳定的，而具体实现可以千差万别。微服务原理和软件工程，面向对象设计中的基本原理相通，体现如下：
单一职责（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”，简言之，这些系统在建成之后反过来还会约束和限制组织的改变。
Fig 1，团队结构和系统架构不匹配
一般企业刚起步时，业务规模小，开发团队规模也小，所以通常开发出来的系统是单块的；随着业务的扩大，团队规模也会随之扩大，这个时候多团队组织架构和单块系统架构之间就会产生不匹配问题（沟通协调成本增加，交付效率低下等等），如果不对单块架构进行解耦和调整以适应新的团队沟通结构，就会制约组织生产力和创新速度。
Fig 2，团队结构和系统架构匹配
把单块架构按照业务和团队边界进行拆分，重新调整为模块化分散式架构（微服务架构是一种方案），那么组织团队沟通结构和系统架构之间又能匹配起来，各个团队才能够独立自治地演化各自的子系统（微服务），这种架构的解耦和调整可以解放组织生产力和提升创新速度。
用户体验适配层
众所周知，随着无线技术的发展和各种智能设备的兴起，互联网应用已经从单一Web浏览器时代演进到以API驱动的无线优先（Mobile First）和面向全渠道体验（omni-channel experience oriented）的时代，如下图所示：
Fig 3，从单一网站到API驱动的全渠道体验
应用架构的新挑战是：
用户接入形式的多样性，无线（手机、Pad），Web，互联网电视，第三方合作应用等等，各种用户设备的屏幕大小，操控体验方式各不相同，例如，手机设备的屏幕较小，能够展示的数据量小，交互方式以触控为主，也可通过条形码扫描器；
有些用户设备的带宽受限，同时应用的UI一般宿主在客户端，有些页面需要组合好几个后台业务服务的数据和功能，如果直接在客户端发起对多个后台服务的调用，势必造成大量网络开销影响性能，这个有点类似数据库查询中的n+1问题。
BFF（Backend For Frontend）是应对上述应用架构挑战的一种模式和最佳实践，2015年底，ThoughtWorks在其网站上刊登了一篇称为BFF@SoundCloud（SoundCloud是一个类似音频YouTube的网站）的文章，讲述SoundCloud如何利用BFF模式逐步将其单块Rails应用迁移改造为支持无线等多种用户体验的微服务架构。
同期，ThoughtWorks的顾问Sam Newman，也就是《Building Microservices》那本书的作者，在SoundCloud等业界实践的基础上，写了一篇博客总结了BFF模式的原理、场景和用法。
BFF本质上是一个后端中间层，但是它的作用主要是适配前端不同用户体验（无线，桌面，智能终端等等），所以称为用户体验适配层，它的适配作用主要是：
裁剪和格式化，对后台的通用数据模型进行适当的裁剪和格式化，以适应不同的用户体验展示的需要；
聚合编排，对后台服务数据进行编排和预聚合，这样可以有效简化客户端逻辑和减少网络调用开销。
转自：https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650992670&idx=1&sn=64c73b94ff05a2ee03239c134aea79ab#rd
