多大的服务 “宜小不宜微”，不宜过大的单体，也不宜滥用微服务，应保持在合适的大小。 （ps. 这里只讨论服务的大小。不讨论服务的手段，拆分解耦、服务发现、mesh、告警、限流、全链路建设，都是好的实践，任何服务都可以做的同样好） 什么样的服务大小属于合理的服务？核心有两点，合理划分服务边界，匹配组织结构。 团队视角：服务的规模应该尽量限制在最小团队，约3人左右的团队为宜 ❎ 过大！跨团队修改同一服务，风险大且不利于基础建设。没有人对整体的架构和质量负责。没有人有全局视角，写代码因为不了解改动范围容易出故障。 ❎ 过大！10人以上的团队不宜修改同一服务。很可能服务定位不清晰，10个人的信息交流会有很多gap，效率会大大降低 ❎ 过小！团队每个人管三四个服务，说明服务数量过多，无用工作会增加，效率也会降低 业务视角：保证产品需求变更如果只在本团队内，修改的服务1-2个即可 ❎ 过小！改一个小小的功能，牵扯4-5个服务。服务太小了，效率降低 ❎ 过大！同时有四五个业务需求，对应数十个研发同时修改一个服务，而这些功能看起来并不密切。这说明服务包揽的功能太多了，已经膨胀的太大了 更微=更好? 我们以一个模块划分合理、大小合适的单体服务为例，看看如果拆分的更微小，对比起来会有哪些点值得关注： 关注点 合理的单体 更微服务 性能 无劣化 约数ms的劣化 复用性 可以仓库内直接引用 不可复用其他仓库代码；所以也不会复用到bug 可读性 容易找代码 需要跨的仓库多，层次深，理解困难 研发成本 编译可能较慢 写代码、编译、调试、发布、部署都需要多仓库并行，成本高 部署成本 单机器 高，需要多台机器 代码合入 公共部分容易冲突 不容易冲突 微服务教 我们看下某网站对单体的批评，一一回应下： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 确实，代码冲突会变多。但在单体内部模块划分合理的情况下，冲突的只会是公共模块；如果这些代码冲突了，使用微服务也会冲突。 代码维护难：代码功能耦合在一起，新人不知道何从下手 耦合是模块设计的问题，不是单体的问题。而且单体断层更少，更容易阅读 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 没发现编译时间有显著区别。部分单体仓库会编译多个产物，建议针对性编译，效果更好。 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 绝对意义上，微服务存在同样的问题，而且更难定位。相对意义上，如果说单体的复用代码带来了问题风险的扩大，这属于因噎废食，不可取。 微服务给我们带来了什么样的反思？拒绝盲目创新，提防吹牛皮但不切实际，小心滥用导致过犹不及。 再次回到起点：monorepo 有趣的是，越来越多人意识到了微服务的问题，最终又回归了单一的仓库，并发明了一新的词：monorepo。 Segment.com 提供活动收集和转发服务，每个客户都需要使用一种特殊格式的数据。因此，工程团队最初决定混合使用微服务和多代码库。这一策略效果很好——随着客户基数的增长，他们扩大了规模，没有出现问题。但是，当转发目的地的数量超过 100 个时，事情开始变得糟糕起来。维护、测试和部署超过 140 个代码库（每个代码库都有数百个日益分化的依赖关系）的管理负担太高了。最终，团队发现他们无法取得进展，三个全职工程师花费了大部分时间来维持系统的运行。 对于 Segment 来说，补救办法就是合并，将所有的服务和依赖迁移到一个单一代码库中。他们必须协调共享库并且测试所有内容，虽然花了很大的代价，但迁移非常成功，最终的结果是降低了复杂性，增加了可维护性。 每个团队的精力是有限的，当每个人管理的仓库>10个，团队管理的仓库>100个，会出现非常多的问题： 团队无法集中注意力管理。有很多的仓库大部分人并不知晓。这部分代码不再能被复用，也不再被了解 开发要打开很多IDE并发进行，容易出错。测试需要部署非常多的服务，也不能跨服务debug。发布时需要发布过多的仓库，发布容易遗漏；发布有很复杂的依赖，发布也会花费更久的时间。 无法发起整体性重构。重构一个服务和同时重构10个服务的难度不是一个级别。

如果你在服务端的工区，常常会听到同学们激烈的讨论，包括能不能扛得住xx流量？能不能P99达到x毫秒？某操作能不能立即生效？某服务CPU飙升了，某服务OOM了，某服务超时率暴涨了？ 这些灵魂的质问，其实就是在保障服务端的高并发、高性能、高可用、高一致性等等，是我们服务端同学必备的扎实基本功。 克服系统瓶颈 服务端的代码都跑在各种版本的Linux之上，所以高性能的第一步要和操作系统打交道。我们的服务需要通过操作系统进行I/O、CPU、内存等等设备的使用，同时在使用各种系统调用时避免各种资源的开销过大。 零拷贝 认识零拷贝之前，我们先要对Linux系统I/O机制有一定的了解。当我们执行一个write(2)或者read(2)的时候（或者recv和send），什么时候操作系统会执行读写操作？什么时候又最终会落到磁盘上？ 以一个简单的echo服务器为例，我们模拟下每天都在发生的请求和回包： 1 2 3 4 5 6 sockfd = socket(...); //打开socket buffer = new buffer(...); //创建buffer while((clientfd = accept(socketfd...)){ // 接收一个请求 read(clientfd, buffer, ...); //从文件内容读到buffer中 write(clientfd, buffer, ...); //将buffer中的内容发送到网络 } 看一下这段代码的拷贝流程（下图）： 数据包到达网卡，网卡进行DMA操作，把网卡寄存器的数据拷贝到内核缓冲区 CPU把内核缓冲区的数据拷贝到用户空间的缓冲区 用户空间处理buffer中的数据（此处不处理） CPU把用户空间的缓冲区的数据拷贝到内核缓冲区 网卡进行DMA操作，把内核缓冲区的数据拷贝到网卡寄存器，发送出去 整个过程触发了4次拷贝（2次CPU，2次DMA），2次系统调用（对应4次上下文切换） （注：DMA(Direct Memory Access)， I/O 设备直接访问内存的一个通道，可以完成数据拷贝，使得CPU 不再参与任何拷贝相关的事情，现在几乎所有的设备都有DMA） 使用mmap mmap可以把用户空间的内存地址映射到内核空间，这样对用户空间的数据操作可以反映到内核空间，省去了用户空间的一次拷贝： 应用调用mmap，和内核共享缓冲区（只需一次） 数据包到达网卡，网卡进行DMA操作，把网卡寄存器的数据拷贝到内核缓冲区 CPU把接收到的内核缓冲区的数据拷贝到发送的内核缓冲区 网卡进行DMA操作，把内核缓冲区的数据拷贝到网卡寄存器，发送出去 整个过程触发了3次拷贝（1次CPU，2次DMA），2次系统调用（对应4次上下文切换） 使用sendfile/splice Linux 内核版本 2.1 中实现了一个函数sendfile(2)： 他把read(2)和write(2)合二为一，成为一次系统调用，实现了把一个文件读取并写到另一个文件的语义 系统调用中不再切换回用户态，而是在内核空间中直接把数据拷贝过去（2.4 之后这一步支持了DMA拷贝，实现了CPU零拷贝） 我门看下使用sendfile之后的流程： 整个过程触发了3次拷贝（0次CPU，3次DMA），1次系统调用（对应2次上下文切换） Linux 内核版本 2.6 中实现了一个函数splice(2)，类似sendfile，但是接收/发送方必须有一个文件是管道，通过管道的方式连接发送方和接收方的内核缓冲区，不再需要拷贝（0次CPU，2次DMA，1次系统调用）