微服务架构：从单机到分布式的革命性升级
本文为学习文章 只用于个人学习用途 可能会有ai生成 与 摘抄自己总结的部分内容
同时也是个人在面试过程中被经常提起的内容 以springcloud为例 展开本文具体内容
先提出问题 传统单机情况下 本地服务的缺陷是什么？ 为什么要用微服务的概念 微服务和原来单机部署情况下有什么不同 要实现微服务 在哪微 怎么体现微 ？
单机服务的缺陷
单机模式下 最直观的问题往往是 可用性 如果流量过大导致系统的所有cpu资源全部被占满 某个中间件 / 某个核心接口被流量冲垮了崩溃了 会出现单点故障（某节点出现问题导致整个系统不可用）并且没有固定的故障恢复的机制 大概率需要人工反复调试 相当复杂 有没有自动路由/自动注册服务的一体化集成？
包括其扩展性也很差 只能不断加cpu / 内存来上硬件 但是成本太高 而且也不能根据每个模块的特定业务需求的实际负载（实际处理请求的能力）不能进行独立的扩展和提高 只能做整条链路上的负载均衡 而且没有限流与熔断相关的熔断/兜底的机制 有没有这种特殊的算法 / 实现范例？
还有就是因为所有人都用一个系统 开发过程中难免遇到个人习惯因素导致的系统强耦合的情况 也就是修改一个地方可能影响全局不可用 这是非常不能接受的 而且任何小改动可能最后需要重新部署整个项目 非常麻烦
包括在技术栈的选型上 所有人都只能公用一套语言和框架 可能会造成系统的滞后性！
所以 微服务为了解决 服务不可用 服务扩展与负载控制 服务降耦合 服务技术开放性 几个方面进行延伸
微服务是什么
相比于之前单机服务在 部署难度 开发难度 不可用保障 每个模块的强耦合上
个人理解微服务将模块进行分区隔离 降低模块间的耦合 也就是把单机拆分成多个微型服务 来协同完成业务（分布式系统实现方式之一） 可以说 微服务就是分布式系统的重要实现方式之一 他们都涉及到多个独立组件通过网络通信协作
区别上来看 微服务更强调服务细粒度 独立性 业务边界性 而分布式是比较广泛的概念 可以是多节点的系统协同完成业务操作 比如数据库的主从 redis 的集群 哨兵分片等等
对应问题的解决方案：
在部署上 微服务可以独立部署 并且以水平扩展的方式来增加模块
技术选型上更为自由和多样 并且实现了分布式架构
每个服务运行在自己的进程里 通过http/restful 这种轻量级机制进行通信
独立的数据存储 既然要避免强耦合 在中间件的选型和实现上也要解耦 数据库需要对于每个服务单独存储
同时 微服务（springcloud）本身也提供很多优秀的组件供业内使用 传统服务在nginx转发路由后直接进入API网关来判断请求url里的服务类型 微服务就是在这里进行优化和爆改 做了更精细 更可靠 与高度扩展的各项功能
微服务各部分组件
服务熔断：为了防止服务因为调用失败超过阈值时 一直重试阻塞流程导致后续服务雪崩 所以微服务采用熔断器来防止请求重复重试，在超过重试次数后打开熔断器 停止再次调用服务
限流：用来控制服务请求速率的技术 防止某个服务因为请求过多而崩溃 在分布式系统里限流可以应用在api网关 服务调用等等 比如sentinel
服务注册和发现；传统情况下 单体服务可能会手动指定服务对应url 前端才能访问后端对应代码 微服务允许服务动态注册自己并且发现其他服务 在分布式相同里 服务注册和发现可应用在多服务之间的通信 比如 eureka 来实现服务注册和发现
配置中心： 用来集中管理微服务工具的配置的工具 允许开发者在运行时动态修改配置 不用重新启动服务 在分布式系统里 配置中心可以用在各个服务的配置管理 比如spring cloud config来实现
API网关： API网关 相对于单机的nginx来说 他是微服务的一个入口点 负责处理客户端请求 并且把请求路由到对应微服务 分布式系统里API网关可以应用在客户端和微服务之间的通信 比如gateway来实现路由转发
分布式追踪： 为了便于定位日志中的出错问题 可以用监控工具来实现定位 比如 skywalking 可以追踪各服务之间的调用日志
消息队列： 最常见的用法就是用来解耦系统组件来实现异步通信 在服务间可以通过消息队列实现异步通信 即使某服务不可用也不会影响整个系统的正常运行 或者在流量过大的情况下 消息队列可以起到削峰填谷 流量削减的作用 把瞬时高并发转化为异步处理的场景 避免系统因为短时间请求量过大导致系统崩溃 同时可以把微服务的日志发送到消息队列里 然后用日志的消费服务系统再统一收集 存储和分析 这样也能减轻每个服务的压力 也便于排查日志和问题
分布式事务：微服务也可以被看做多个节点之间相互协作而产生的结果 除了基本的服务间调用所用到的通信协议 同时也需要保证数据一致性 为了保证全流程操作一致性 市面上有许多分布式事务 比如 2pc 3pc saga tcc等等 以及利用消息队列可靠性传输来确保事务参与和主事务状态保持一致 2pc指 协调者 tc询问各个参与者是否可执行事务提交 如果所有参与者都同意 那么tc再给所有参与者发送正式提交请求 虽然保证强一致性但是会有同步阻塞的问题 性能很低
3pc 是对2pc的改进 也就是增加了pre提交阶段 减少参与者的阻塞范围
Sagas 在seata组件里的saga模式 使用状态机实现 一种是原始的基于监听事件驱动的实现（步骤比较少的情况 还有可能产生环形监听 两个业务互相监听对方产生的事件） 还有一种是基于命令的实现（定义协调者（协调中心）管理事务）中间会涉及到状态机的编排 并且协调中心独立（需要维护）
tcc 手动锁定资源 预操作资源try 再验证实现 confirm 失败后撤销操作 cancel
实现方式与部署
单体就是直接部署 一体化流程 可能就最后需要devops
微服务的部署可以通过云计算来实现
云计算的特点：可以根据需求动态分配资源 天然提供自动化部署 监控 和 管理工具 包括提供负载均衡 服务发现等等 比如云厂商（阿里云 腾讯云 华为云等等）就提供一体化服务