mikey是什么意思中文翻译,mikey是什么中文意思

　　如何才能设计出灵活的面向体验的微服务架构，以满足当今无线优先、全渠道用户体验的需求和挑战？它的模式和最佳实践是什么？携程、网飞、SoundCloud等知名互联网公司是如何实践体验导向的微服务架构的？在刚刚过去的2015年，丹尼尔马丁福勒对微服务有哪些新的看法？　　

　　

　　微服务有不同的玩法，我发现有些术语是不同公司叫的。可以说，微服务还在剧烈的进化中，这个领域还没有成熟和规范，所以今天的分享主要是我个人的观点和总结，目的是抛砖引玉，启发进一步的探索和实践。　　

　　

　　此次分享的话题包括：　　

　　

　　微服务架构原则　　

　　

　　用户体验适配层(后端对前端)　　

　　

　　携程无线微服务案例分享　　

　　

　　网飞微服务架构分析　　

　　

　　SoundCloud微服务架构分析　　

　　

　　微架构不是免费的午餐　　

　　

　　摘要　　

　　

　　这次分享也是应建筑组一些朋友的要求，将之前零散的内容汇总成文字形式。在这个分享过程中，会发布相关内容参考链接(部分来自SlideShare和网飞techblog的链接需要**访问)，供感兴趣的朋友进一步了解。　　

　　

　　一、微服务架构原理　　

　　

　　微服务是一个新概念，但是并没有一个明确的定义，各家对微服务的描述也不尽相同。我更喜欢用一些架构原理来描述，因为架构原理相对抽象稳定，具体实现可以千差万别。微服务原则与软件工程和面向对象设计的基本原则是相通的，具体体现如下：　　

　　

　　单一责任，一个服务应该承担尽可能单一的责任，服务应该基于一个有界的上下文(通常是一个边界清晰的业务领域)来构建。改变服务理想的理由应该只有一个(类似罗伯特c马丁说的：一个班级应该只有一个改变的理由)。当一个服务承担了过多的职责时，就会出现各种耦合问题，需要进一步拆分，使其职责尽可能单一。　　

　　

　　关注点分离，交叉逻辑，如日志分析、监控、限流、安全等。应该尽可能脱离具体的业务逻辑，让开发人员专注于业务逻辑的开发，减轻自己的思维负担。这也是有界语境的一种表现。　　

　　

　　模块化和分而治之，是解决复杂问题的通用方法，把大问题(比如单片架构)做大，把小问题(模块化和微服务)做小，然后分而治之。　　

　　

　　服务架构也是一个组织原则的体现，这就是康威法则。梅尔文康威(Melvin Conway)在1968年指出：“任何设计一个系统(广义定义)的组织都会产生一个设计整体结构是组织的沟通结构的副本”，翻译成中文，意思是：设计系统的组织，由此产生的设计和架构相当于组织之间的沟通结构。诺斯还补充道：“这些制度为组织变革提供了选择”。简而言之，这些制度建立起来之后，会反过来制约和限制组织变革。以下两幅图进一步解释了这一组织原则：　　

　　

　　　　

　　

　　图1，团队结构和系统架构不匹配。　　

　　

　　一般企业起步时，业务规模小，开发团队少，所以通常开发的系统是单块的；随着业务的扩大，团队规模也会扩大。这时候就会出现多团队组织结构和单块系统结构的不匹配(沟通协调成本增加，交付效率低等。).如果不对单块架构进行解耦和调整以适应新的团队沟通结构，将会制约组织生产力和创新速度。　　

　　

　　　　

　　

　　图2，团队结构和系统架构匹配　　

　　

　　如果按照业务和团队的边界拆分单片架构，重新调整为模块化的去中心化架构(微服务架构是一种方案)，那么组织团队和系统架构的沟通结构是可以匹配的，每个团队都可以独立自主地演化出自己的子系统(微服务)。这种架构的解耦和调整，可以解放组织生产力，提高创新速度。　　

　　

　　第二，用户体验适配层(Backend For Frontend)　　

　　

　　众所周知，随着无线技术的发展和各种智能设备的兴起，互联网应用已经从单一的网页浏览器时代发展到API驱动的无线优先、面向全渠道体验的时代，如下图所示：　　

ikey是什么意思中文翻译,mikey是什么中文意思3.jpg">

　　

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本质上是一个后端中间层，但是它的作用主要是适配前端不同用户体验（无线，桌面，智能终端等等），所以称为用户体验适配层，它的适配作用主要是：

　　

裁剪和格式化，对后台的通用数据模型进行适当的裁剪和格式化，以适应不同的用户体验展示的需要；

　　

聚合编排，对后台服务数据进行编排和预聚合，这样可以有效简化客户端逻辑和减少网络调用开销。

　　

下图展示了一个无线BFF：

　　　　

Sam推荐理想情况下针对每种用户体验类型需要一个BFF（one BFF per user experience），例如Mobile BFF，Desktop BFF，这可以做到职责单一和关注分离（遵循有界上下文原则），但是BFF过多也会造成代码逻辑重复冗余的问题，需要权衡。UI和BFF理想是同一个团队负责，这样可以减少沟通协调成本，加快变更迭代速度，这是遵循康威定律的体现。下图展示了一种BFF和团队职责边界划分方案。

　　　　

Sam还指出，对于一些跨横切面的关注点（cross cutting concerns），例如路由，安全认证，日志监控分析，限流等等，通常可由独立的***（Gateway）层负责（如Fig 6所示），由独立基础设施团队运维，置于BFF之前，这样在架构上可以做到职责单一和关注分离，让BFF开发人员专注于聚合裁剪等业务功能，无需考虑跨横切面功能。但是如果对运维成本和调用性能有额外考虑，跨横切面的功能也可以直接做在BFF一层。

　　　　

Fig 6，独立***层负责跨横切面功能

　　

三、携程无线微服务案例分享

　　

携程网是一家旅**业的互联网公司，其内部有约十几个大小不同的事业部（也称战略事业单位，Strategic Business Unit，SBU）组成，例如机票，酒店，度假等等。三四年前，为迎合无线互联网的趋势，和很多其它互联网公司一样，公司成立了一个独立的无线事业部（也是一个SBU），统一为整个公司开发无线应用。下面两个图分别是携程无线H5应用的首页（Fig 7），和最初的无线架构（Fig 8）：

　　　　

Fig 7，携程无线H5首页

　　　　

Fig 8，最初的携程无线架构

　　

架构底层是企业传统的SOA/ESB/DB服务，架构上层是用户的无线设备，中间是用户体验适配层BFF。携程针对两类不同的用户体验分别做了两个BFF：

　　

Mobile App BFF： 针对iOS，Android等Native和Hybrid应用场景，采用定制的TCP协议和二进制消息以提升网络传输性能，

　　

H5 BFF：针对HTML5浏览器应用场景，采用标准REST/JSON协议通讯。

　　

最初，携程无线BFF是单块的（Monolithic），BFF由无线事业部集中开发，涵盖其它所有SBU（酒店、机票、度假等）的聚合裁剪逻辑。刚开始，携程无线应用相对简单，单块BFF有优势，例如开发、测试和部署集中简单，运维和集群扩容也比较方便。

　　

但是随着时间的推移，特别是近两年，使用无线应用的用户数成倍增长，无线应用的功能也变得越来越复杂，康威定律逐渐发挥作用，无线SBU和其它业务SBU之间的沟通协调成本越来越高，相互之间还常常因沟通不畅而产生摩擦，交付效率越来越低。同时，单块BFF还具有代码逻辑耦合臃肿，集群故障概率高，技术栈绑死，阻碍快速创新等单块架构固有的缺陷。

　　

2014年，携程对组织架构进行了一次调整，将原无线事业部拆分，将无线团队打散并安排到各个SBU业务事业部中。为配合组织架构的调整，公司的技术架构团队也将原来的单块BFF架构升级到如下的（Fig 9）面向体验的微服务架构：

　　　　

新架构中，原来的单块BFF被拆分到各个SBU独立开发、测试、部署和运维。新架构中引入了一个API***层（API Gateway），是服务解耦自治的关键，主要负责服务反向路由，同时负责限流容错、安全、日志、监控等跨横切面的公共逻辑。BFF解耦之后，携程微服务架构和组织业务架构进一步对齐，职责更明确，交付效率和创新速度明显加快。

　　

四、Netflix微服务架构分析

　　

Netflix是一家美国的在线影像租赁服务提供商，早在2012-2013年左右，Netflix就已经建立起了比较成熟的微服务架构体系。值得一提的是，Netflix还把它的整个微服务技术栈开源出来贡献给了社区，参考，其中包括知名的开源服务***Zuul，服务注册发现框架Eureka，服务端框架Karyon，客户端框架Ribbon，容错组件Hystrix等等，可以说Netflix对微服务架构的发展起了重要的推动作用。下图展示了Netflix的微服务技术栈，来自Netflix参考应用rss reader，其中带粉红色标注的组件和Zuul都是开源的：

　　　　

下图是我对Netflix微服务技术栈的一个简化和抽象，可见整个微服务体系的骨架：

　　　　

Netflix的微服务体系可以简化为两层服务：

　　

边界服务层（Edge Service Layer），本质上就是BFF，适配前端各种用户体验的API层，

　　

中间层服务（Middle Tier Service），Netflix后端的各种微服务的统称。

　　

Netflix的微服务体系由两个重要的基础设施支撑：

　　

服务***（API Gateway），是Netflix微服务的总入口，负责反向路由，安全，限流容错，日志监控等跨横切面的功能，

　　

服务注册表（Service Registry），负责***到边界服务，边界服务到中间层服务，以及后台服务之间的软路由和软负载。

　　

关于Netflix微服务和API架构的更多内容，推荐参考SlideShare上的两个ppt：

　　

Transforming the Netflix API

　　

Netflix’s Global Edge Architecture

　　

架构技术是程序员绕不开的话题，关于分布式，微服务，源码，框架结构，设计模式等这些技术我都分享在群650385180，可免费下载。希望可以帮助在这个行业发展的朋友和童鞋们，在论坛博客等地方少花些时间找资料，把有限的时间，真正花在学习上，我把这些视频分享出来。相信对于已经工作和遇到技术瓶颈的码友，在这个群里一定有你需要的内容。

　　

下面的一些图片是从上面两个ppt中截取出来的。

　　

Netflix需要针对超过一千种的设备提供服务，这对他们的API层（也就是边界服务层或者BFF层）的设计提出了很大的挑战，为了应对这种挑战，Netflix的UI团队和API团队通力协作，由API团队提供通用的API运行时平台（有点类似PaaS for API的概念），UI团队则在API运行时平台上针对不同设备利用动态脚本开发不同的API端点，这种模式最大化了UI团队的效率和灵活性，如下图所示：

　　　　

Fig 12，UI和API团队协同开发API

　　

Netflix的API运行时平台内部细节和运作方式如下图所示：

　　　　

Fig 13，动态脚本平台

　　

Netflix的API运行时平台由API团队负责开发和运维，其中内置支持：

　　

通用的调用后台服务的SDK；

　　

支持并发调用多个后台服务的异步服务层（基于RxJava）；

　　

容错组件Hystrix。

　　

UI工程师利用Groovy脚本根据前端设备展示的需要开发API脚本，通过SDK调用后台服务，对后台服务和数据进行聚合裁剪，开发完成的脚本通过端点管理器上传到API运行时平台上，最后激活该脚本则对应的API端点就能生效对外提供服务。Netflix API运行时平台也称为动态脚本平台（Dynamic Scripting Platform），更多细节可参考和。

　　

Netflix应用采用前后分离架构，页面等静态资源置于CDN上，用户设备从CDN直接加载页面，交互时页面直接从后台边界服务层获取数据，如下图所示：

　　　　

下图是Netflix API在AWS上的部署架构:

　　　　

注：最新的Netflix开源项目Falcor表明Netflix同时也采用基于Node/JS技术的裁剪适配层，目的是给前端UI团队更大灵活性和自主权。Facebook有一个类似的项目GraphQL。

　　

五、SoundCloud微服务架构分析

　　

SoundCloud是一家音频分享网站，有点类似音频界的YouTube，最近SoundCloud在SlideShare上分享了他们的微服务架构和实践。

　　　　

Fig 16，SoundCloud微服务架构一

　　

上图是从SoundCloud的一个ppt截取的微服务层次结构图，和Netflix/携程类似，两个主要层次是：

　　

边界服务层（Edge Layer），相当于BFF，针对不同场景体验的适配层，例如第三方集成的Public API，嵌入页面场景的Api-embedded，无线场景的Api-mobile和桌面应用场景的Api-v2。

　　

微服务层（Microservices），SoundCloud后台微服务的统称，例如messages、stats、likes服务等等。

　　

下图是从SoundCloud另一个PPT截取的微服务架构图。

　　　　

Fig 17，SoundCloud微服务架构二

　　

有两点值得关注：

　　

SoundCloud将Geoip、限流、安全认证等跨横切面功能和BFF做在同一层，没有像Netflix/携程一样做在独立的***层，SoundCloud的这一做法有性能优势，但同时也增加了BFF层的复杂性；

　　

SoundCloud将后台微服务又分为两层，最底层的基础服务层（Foundation Service Layer）和中间的增值服务层（Value-added Service Layer），这种分层方式是SoundCloud根据自己的需要提出的一种逻辑划分。

　　

关于SoundCloud微服务架构的更多内容，请参考SlideShare上的两个PPT：

　　

BFF Pattern in Action: SoundCloud’s Microservices

　　

Microservices@SoundCloud

　　

六、微服务架构不是免费的午餐

　　

上面分享的三家公司都是体量比较大的互联网公司，他们的业务量和团队规模决定他们很难不采用微服务架构，但是对中小型规模的公司来说，这三家的架构未必是可以直接照搬的，个人认为，解决问题的scope不同，所采用的架构一般也不同，不能盲目照搬。

　　

在业界对微服务架构热情高涨之际，马丁福勒在2015年陆续写了几篇文章，让人们更客观理性地看待微服务，建议大家进一步阅读：

　　

微服务架构先决条件

　　　　

马丁说，你必须长足够高，才可以考虑使用微服务，这里的高就是指基本的研发能力，包括：

　　

快速的环境提供（Rapid Provisioning）能力，理想有基于云的环境提供能力。

　　

基本的监控 (Basic Monitoring）能力。

　　

快速的应用发布（Rapid Application Deployment）能力。

　　

DevOps文化。

　　

架构技术是程序员绕不开的话题，关于分布式，微服务，源码，框架结构，设计模式等这些技术我都分享在群650385180，可免费下载。希望可以帮助在这个行业发展的朋友和童鞋们，在论坛博客等地方少花些时间找资料，把有限的时间，真正花在学习上，我把这些视频分享出来。相信对于已经工作和遇到技术瓶颈的码友，在这个群里一定有你需要的内容。

　　

在没有建立起这些能力之前，勿轻易跟风采用微服务架构，上面分享的三家公司，都是在具备这些基础研发能力的基础上才开展微服务的。

　　

微服务的附加成本

　　　　

马丁指出，当业务不复杂，团队规模不大的时候，单块架构比微服务架构具有更高的生产率（productivity），原因在于建立微服务架构需要额外的开销来支持和管理微服务，从而降低生产率；但是随着业务复杂性的增加和团队规模的扩大，单块架构比微服务架构的生产率下降更趋明显，当复杂性达到一个点，微服务架构的生产率会优于单块架构，原因在于微服务的松散耦合自治特性减缓了生产率的下降趋势。

　　

注：马丁在上图的右下角提出了一个很有意思的观点，团队的技能是比单块或者微服务架构的选择更重要的因素。说白了，如果团队能力不行，不管用单块还是微服务，还是难于管理复杂性。

　　

反过来，如果团队能力强，不管用单块还是微服务，都能找到好的管理复杂性的手段，所以说团队的技能才是管理复杂性的关键。

　　

单块优先(Monolith First)

　　　　

马丁说，他不建议企业应用一开始就直接上微服务架构，原因一方面是支持微服务架构需要额外的开销来管理分布式复杂性，另一方面是刚开始系统复杂度和领域边界是不清晰的，你不知道该如何正确的切分微服务，所以这种方案常常具有很高的失败风险。

　　

马丁建议企业应用走单块优先的架构思路，先轻装上阵，赢得时间探索系统的复杂性和领域边界，当复杂性增加时，拆出部分微服务，随着团队对服务边界更加清晰和服务管理能力的提升，持续拆分出更多微服务，最终演化出微服务架构。

　　

上面分享的案例中，像携程/SoundCloud都是从单块架构起步，随着业务和团队规模的增长不断调整其架构，最终演化出微服务架构，SoundCloud从单块到微服务演化经历可参考。

　　

七、总结

　　

1、微服务架构是一种支持演化的自适应的架构，微服务架构本身也是演化的结果，架构演化的主要驱动因子是：

　　

经济达尔文：从长远看，只有那些能更好满足客户需求的企业才能生存。简单讲就是业务驱动，业务要求架构灵活易于变更和扩展，易于升级替换，发布快速，高可用能应对不可预测的流量模式，能支持多样的用户设备和体验，这样才能加快业务创新的速度，赢得客户和竞争优势；

　　

无线、智能设备和云等技术的进步和发展；

　　

康威定律，即企业的业务、组织和系统边界要尽可能对齐，以业务领域和微服务为边界的产品型跨职能团队能更敏捷地响应市场需求。

　　

2、系统架构的首要目标是管理复杂性，遵循良好的架构原理，如单一职责、有界上下文、关注分离、模块化和分而治之，是管理复杂性的有效手段。在企业应用成长到一定规模以后，微服务架构是管理复杂性的一种行之有效的架构风格。

　　

3、企业要不要用微服务，取决于你的业务复杂度和团队规模，一般Monolith First。业界大型互联网企业的微服务架构可以参考和学习，但是不能照搬，解决问题的scope不同，采用的架构也不同。

　　

4、BFF（Backend For Frontend）是应对当前多种用户体验的一种模式和最佳实践，BFF的主要作用是针对不同的用户体验对后台服务和数据做聚合裁剪适配。用户体验适配层，BFF，API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相似概念。

　　

5、Client -> API Gateway -> BFF -> Downstream Microservices，是面向体验的微服务的标准参考架构。

　　

6、2016年的参考应用架构如下图所示，引用自ThoughtWorks的文章<技术栈复杂度飙升给管理者们的启示>>，特点：

　　

企业后台采用微服务架构，微服务可以采用不同的编程语言和不同的存储机制；

　　

企业前台采用BFF模式对不同的用户体验（如桌面浏览器，Native App，平板响应式Web）进行适配；

　　

企业后台采集各种数据，集中存储，再进行大数据建模、分析和预测，计算出来的数据再以微服务方式反哺给前台页面（例如商品推荐）。

　　　　

附录

　　

很多不错的文章，有兴趣的同学可以参与翻译。

　　

1、BFF@SoundCloud https://www.thoughtworks.com/insights/blog/bff-soundcloud

　　

2、Pattern: Backends For Frontends http://samnewman.io/patterns/architectural/bff/

　　

3、Netflix Open Source Software Center http://netflix.github.io/

　　

4、Netflix Dynamic Scripting Platform http://techblog.netflix.com/2014/03/the-netflix-dynamic-scripting-platform.html

　　

5、Falcor, A Javascript library for efficient data fetching https://github.com/Netflix/falcor

　　

6、技术栈复杂度飙升给管理者们的启示 http://www.neucloud.cn/article/1399_The-inspiration-of-the-technology-stack-complexity-surge-to-managers.html

　　

7、微服务架构先决条件 http://martinfowler.com/bliki/MicroservicePrerequisites.html

　　

8、微服务的附加成本 http://martinfowler.com/bliki/MicroservicePremium.html

　　

9、单块优先（Monolith First） http://martinfowler.com/bliki/MonolithFirst.html

　　

10、Introducing the first NetflixOSS Recipe: RSS Reader http://techblog.netflix.com/2013/03/introducing-first-netflixoss-recipe-rss.html

　　

11、Optimizing the Netflix API http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

　　

12、Transforming the Netflix API http://www.slideshare.net/benjaminschmaus/bschmaus-apiworldtransformingnetflixapi

　　

13、Netflix’s Global Edge Architecture http://www.slideshare.net/MikeyCohen1/edge-architecture-ieee-international-conference-on-cloud-engineering-32240146

　　

14、BFF Pattern in Action: SoundCloud’s Microservices http://www.slideshare.net/grandbora/bff-pattern-in-action-soundclouds-microservices

　　

15、Microservices @ SoundCloud http://www.slideshare.net/grandbora/microservices-soundcloud

　　

16、GraphQL A data query language and runtime http://graphql.org/

　　

互动问答

　　

问题：微服务与SOA的区别是什么？

　　

我觉得两者体现相通的架构原理：单一职责，有界上下文，关注分离，分而治之。区别在于微服务粒度更细，同时融入了近几年一线互联网公司的一些最佳实践，是服务化的新提法。

　　

问题：API***的反向路由的设计思路能具体说明一下吗？

　　

携程的API***基于Netflix的Zuul开源组件。对外暴露一个域名api.ctrip.com，根据第一级目录做反向路由。

　　

api.ctrip.com/hotel，api.ctrip.com/flight，api.ctrip.com/vacation。每一级目录，如hotel, flight, vacation对应一个后端BFF集群的域名，也就是说Gateway里头有一张映射表，这张表示是可以动态配置的，可以动态路由，灰度，蓝绿部署都可以通过这张映射表做出来。

　　

问题：分布式数据一致性问题在实践中是怎么解决的？最终一致性方案中的event-driven和event sourcing或其他方案实践中是怎么选型的？有没有推荐的参考框架或方案？

　　

event-driven和event sourcing是Chris Richardson推崇的，他最近还到DaoCloud做演讲。推荐阅读：

　　

微服务系列之「事件驱动型微服务」

　　

http://blog.daocloud.io/chris-richardson-1/

　　

Chris Richardson 微服务系列之「事件溯源（Event Sourcing）型微服务」

　　

http://blog.daocloud.io/chris-richardson-2/

　　

Chris Richardson 微服务系列之「最佳实例：Eventuate」

　　

http://blog.daocloud.io/chris-richardson-3/

　　

Chris Richardson在他的GitHub上还做了一个event-sourcing的样例，值得参考：

　　

https://github.com/cer/event-sourcing-examples

　　

我本人觉得还是复杂了，如果简单场景实时性要求不高，简单队列订阅解决分布式一致性问题。

　　

问题：微服务的分布式事务该怎么做？如果做二次提交怎么处理回滚？

　　

分布式事务尽量避免。《如何用消息系统避免分布式事务？》这篇文章的方法简单可以参考：http://www.cnblogs.com/LBSer/p/4715395.html

　　

问题：微服务感觉就像是服务的模块化，那么如果我一个业务需要多个服务那该在哪里调用这些服务，这么理解对吗？

　　

微服务本质就是模块化，分布式模块化。“如果我一个业务需要多个服务那该在哪里调用这些服务”：BFF，或者中间层的聚合编排服务。

　　

问题：1、微服务架构下，数据库该如何部署呢？有的说一定要每个服务单独部署，有的说要服务共享数据库，您的意见是怎样的？ 2、服务在拆分，部署的时候有什么设计原则吗？

　　

1、要看情况，不能绝对的。2、拆分理想按照领域边界，团队边界拆，这个也是不断演化的。

　　

问题：微服务如果变多了有什么办法管理呢？极端点如果有一千个怎么办？

　　

我当时在eBay维护Trading API，也就是eBay最大的一个API，有差不多160多个API。这个维护成本已经很高了，也是跟eBay的体量相对应的。服务拆分到多细粒度，要根据具体情况的，原则虽然是职责单一，但也要看你的团队和资源的限制。目前我所在公司40多号人维护一个网站，我估计最多也就拆出20~30个服务，再多维护不过来。原则是一种指导，但是具体实施要看上下文。

　　

企业真的到了一定体量，按业务要求服务越来越多，Netflix内部微服务应该超过千个，阿里巴巴也超过千个，这个时候要靠基础设施和自动化了，需要微服务基础设施，监控，DevOps和持续交付平台支撑成千上万的微服务，我认为管理复杂性主要靠三个支柱：

　　

基础设施平台自动化

　　

人才密度

　　

遵循好的架构原则和最佳实践

　　

号外号外

　　

给大家推荐一个交流学习群：650385180里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多：