现如今当我们打开各大互联网企业的技术分享文章的时候微服务架构永远是出现频率最高的技术关键词淘宝、京东、抖音、微信后台这类体量庞大的线上平台全部基于微服务架构搭建整套业务体系。很多初学后端开发的同学长期听过这个概念却无法理解微服务到底解决了单体项目的哪些痛点拆分服务的划分依据是什么本篇避开晦涩专业术语用通俗易懂的逻辑讲清微服务架构的设计思想与落地价值。其实最容易理解微服务的方式就是先对比传统单体架构项目的弊端。单体架构指整个产品所有业务功能全部集成在同一个项目工程中用户注册登录、商品上下架、下单创建订单、支付扣款、物流信息推送、评价管理、优惠券发放等数十项业务代码全部写在一个项目内打包之后部署在服务器上运行。项目初期业务简单、用户量少的时候单体架构开发速度快、部署流程简单具备一定优势但只要产品业务持续迭代扩张单体项目的短板会被无限放大。首先是代码耦合严重不同业务模块互相调用纠缠修改订单模块的一行代码有可能影响到支付、优惠券、库存多个关联功能每次版本迭代哪怕只改动一个小需求都需要将整个项目全量打包重新发布上线风险极高一旦发布出现 bug全线功能都会受到影响。其次是故障扩散无法隔离单体项目是单一进程运行任意一处代码出现死循环、内存溢出、数据库死锁等异常会直接导致整个项目进程崩溃网站所有页面全部无法访问一次局部故障就能造成整个产品服务瘫痪。资源调度僵化也是单体架构的一大硬伤电商平台在促销活动期间下单与支付接口访问量会暴涨数十倍但是商品详情、个人中心模块访问压力很小单体项目无法单独给订单模块增加服务器算力只能整体扩容整套项目大量服务器资源分配给低访问量模块造成严重的资源浪费企业服务器运维成本居高不下。除此之外单体项目只适合小型团队协同开发项目代码量突破十万行之后多人并行开发极易出现代码冲突版本管理繁琐大型团队拆分小组分工协作几乎无法实现。微服务架构的核心解决思路就是按业务域拆分、服务独立化运行。把原本耦合在一起的单体大项目按照业务边界拆分成多个体量小巧、职责单一的独立服务。比如电商系统可以拆分为用户服务、商品服务、订单服务、支付服务、库存服务、物流服务、营销优惠券服务每一个服务只处理自身对应领域的业务逻辑拥有独立的代码仓库、独立的数据库、独立的部署实例各个服务之间通过远程接口调用完成数据交互互相之间不侵入对方内部代码。拆分之后各项痛点迎刃而解迭代更新时只需要打包发布需要改动的单个服务不会影响其他业务模块上线风险大幅降低某一个服务因为流量过大或者代码问题崩溃其余服务依旧正常运行不会发生全线宕机针对高并发的订单、支付服务可以单独批量扩容节点低流量服务维持少量实例即可服务器资源按需分配极大节约硬件成本不同研发小组可以分别负责不同服务的开发维护代码仓库完全隔离不会出现大规模代码冲突团队协作效率显著提升。当然了微服务架构也会带来新的技术复杂度需要配套服务注册发现、配置中心、链路追踪、分布式事务、网关路由、熔断降级等中间件组件来治理分布式场景下的各类问题所以小型项目盲目拆分微服务反而会增加开发运维成本。行业内通用的选型思路是初创小项目使用单体架构快速落地业务规模与团队体量增长之后再逐步拆分向微服务架构演进这也是绝大多数互联网公司的技术架构迭代路径。