微服务相比传统服务的优势

这是一道面试题，咱们先来分析这道题考察的是什么。

如果分析面试官主要考察以下几个方面：

1. 技术理解深度

• 你是否清楚微服务架构（Microservices）和传统单体架构（Monolithic）的本质区别。

• 能否从设计理念、技术实现、适用场景等维度对比两者。

• 实际经验与场景化思考

• • 是否在项目中应用过微服务，能否结合案例说明优势（如提升开发效率、解决扩展性问题等）。

  • 能否辩证看待优势（例如微服务并非银子弹，会带来复杂度上升）。

• 系统设计能力

• • 是否理解架构选择背后的权衡（Trade-offs），例如团队规模、业务迭代速度对架构的影响。

• 技术趋势认知

• • 是否关注云原生、DevOps 等与微服务相关的技术生态（如 Kubernetes、Service Mesh）。

  那在回答这道题的时候就需要进行适当的扩展体现这部分的能力。但是同时要注意避免面试官觉得你跑题，所以在介绍每个优势之前可以先做一个总结性的：这个问题我会结合对技术的理解、实际经验、技术选型决策与技术趋势几个方面来说。

  ‌高内聚、低耦合‌

  微服务架构将一个大型应用拆分成多个小型、自治的服务，每个服务都围绕特定的业务功能进行构建，具有高度的内聚性。各个微服务之间通过轻量级的通信机制（如RESTful API）进行交互，耦合度极低。这种特性使得每个微服务都可以独立开发、测试、部署和运维，极大地提高了开发效率‌。

  在多人维护单体应用的时候，可能很多人都遇到过代码冲突的困境。代码冲突本质上是耦合度高的外在表现。之前一个项目中由于服务还没有做拆分，还要一个人兼顾好几个项目的开发，多分支切换。导致每次发布生产前要花半天的时间做冲突合并。

  有次合并后有个地方没有冲突，但是代码逻辑是老的（和提交顺序有关）。被指出来之后人家说因为没有冲突，就不是人家的问题。这种不对结果负责的态度也就只能给个眼神过去。（实际面试时注意这种话是不能说的哦）

  但是这种代码一旦上线造成后果，那就面临损失，服务拆分是合理的解决方案。

  ‌独立部署和灵活扩展‌

  微服务是独立的应用，可以单独上线或更新，不需要停掉整个系统。这种设计使得部署更灵活，降低了发布风险，并且可以根据流量压力独立扩展，只对流量大的服务增加资源，而不用浪费资源扩展整个系统‌。

  试想你有一个服务，原本上面的CURD接口有按照主键的增删改查（称为A类）和批量查询（称为B类）两部分。A类可用性要求4个9。B类可用性要求2个9。这种情况下A类和B类独立部署A类可能要求三地六中心部署，B类其实只要部署在1个机房里就满足要求了。A类是核心业务，可以设置弹性伸缩策略，比如CPU大于80%时自动扩容，CPU持续1分钟小于60%时自动缩容来保证可用性。而对于B类业务设置弹性伸缩策略会增加成本，必要性也不是很大。

  技术多样性‌

  每个服务可以选择最适合的技术栈。例如，订单服务可以用Java，AI服务可以用Python。这种灵活性支持技术创新，团队可以尝试使用新技术，而不必担心影响其他服务‌。

  ‌按业务能力划分服务与组织团队‌

  微服务架构将应用按业务能力划分为不同的服务，每个服务要求在对应业务领域的全栈软件实现。这种组织方式跨功能，包含实现业务所需的全面技能，有助于提高开发效率和团队协作‌。

  ‌服务即产品‌

  传统的应用开发是基于项目模式的，而微服务架构将每个服务视为一个独立的产品。这种模式使得服务的开发和维护更加灵活，能够更快地响应市场变化‌。

  下面的这个案例，如果不是采用微服务的架构，这种演进是很难做到的：

  我们团队负责的有一个叫基础数据的服务，这个服务连接了全公司唯一一个六机房平等的数据库，六机房平等是指虽然写入数据在同一个机房，但数据可以六机房平等的读。公司的其他团队也想使用这个数据库，所以开始时我们承接了很多其他团队的个性化需求，导致了团队成员为了支撑需求，疲于奔命。接到的需求在技术上很简单，都是一些后台操作数据，延迟要求不高的场景，CURD操作数据库，技术含量低，维护人员平均半年就会转岗或离职。我来了之后，对数据模型进行了抽象，将原本要开发成一张张数据表的，统一在一张数据表里，用json格式来存储，我们提供SDK给用户使用，里面提供了json和POJO的转换等工具尽量符合之前的使用习惯。用户不用再等我们开发，而是可以在后台配置出他们需要的数据表定义，进行数据操作。这种方式，第一我们团队无需开发支持需求快，第二，需求团队开发量也减少了，因为本来是他们需要自己做后台数据管理的界面。但难点是用户不接受。原因首先是和原来的使用习惯不同，第二是他们担心稳定性问题。统一数据表，数据上不隔离，还要使用我们的SDK。我当时做了很多的宣讲，关键代码挨行的给用户解释，开始时也只接入了一些非核心的系统。我们慢慢把系统做好做强，直到我们自己的核心系统也接入，大家才开始慢慢接受。因为我们的核心系统是关键的系统，这个说服力比较强。但还有一个关键难点，就是系统的定位，开始时想把它定位为配置中心，因为在功能和管理上和携程阿波罗配置中心很像，但是领导对中心这个词很敏感，因为中心意味着出了问题影响范围大。后来经过仔细梳理思考，这个服务对数据做了严格的管控，包括标准的审核流程、严格数据准入、灰度生效、数据变更过程追踪、一键回滚、定时生效、临时生效等。并且数据可以不存我们的数据库，外接数据源。所以最终定位为数据变更管控系统。因为业界代码变更管控的产品相对成熟，数据变更管控的产品非常少，我们也在持续的完善它，希望能将它打造成业界标杆的产品。