第一篇基础与定义图1什么是微服务根据微服务之父马丁·福勒的描述微服务架构是一种架构模式它提倡将单一应用程序划分成一组小的服务每个服务运行在独立的进程中服务之间采用轻量级的通信机制通常是HTTP的RESTful API互相协作。核心特征小服务、独立进程、轻量通信、独立部署、去中心化管理。图2系统架构的演进之路架构不是凭空产生的而是不断演化出来的。从互联网早期到现在大体经历了以下几个过程单体架构所有功能部署在一起开发成本低但维护困难。垂直架构按业务模块切分应用解决了流量分担问题但存在重复代码。分布式架构抽取公共业务层提高复用性但调用关系复杂。SOA架构引入ESB治理中心解决资源调度问题但依赖关系重。微服务架构彻底的服务化拆分强调原子化和独立部署。第二篇核心组件篇如果把微服务比作一家大型公司那么这些组件就是保证公司正常运转的关键角色。图3服务注册与发现在微服务架构中服务的位置是动态变化的扩缩容、故障迁移。如何找到对方核心工作原理注册中心维护所有服务的地址信息服务名称、IP、端口。服务提供者启动后将自己的信息注册到注册中心并定期发送心跳维持可用状态。服务消费者调用服务时先询问注册中心获取地址再通过负载均衡发起调用。主流的注册中心有Eureka、Consul、Zookeeper、Nacos。图4三种服务发现模式对比主流的服务发现分为三种DNS模式开发找运维配域名缺点是没有负载均衡功能。客户端发现Spring Cloud模式客户端内置负载均衡轮询注册中心如Eureka。这是目前普遍的做法但对多语言环境不太友好。服务端发现Kubernetes模式客户端通过Kubernetes Service访问由Kube-proxy进行转发。图5API网关——系统的唯一入口网关是整个系统对外暴露的唯一大门封装了系统内部的所有微服务。它的作用就像是公司的门卫反向路由将外部请求转换成内部具体服务调用。安全认证识别恶意访问和黑客攻击。限流熔断防止请求过多压垮服务。日志监控记录所有入口流量。灰度发布支持A/B Testing让部分用户体验新功能。常见的开源网关有Zuul、Spring Cloud Gateway、Kong。图6配置中心以前配置文件放在项目里一旦需要大规模改动配置改动时间会很长且无法追溯配置人员。配置中心将配置从代码中剥离出来集中管理。作用实现配置的运行时动态更新无需重启服务。主流产品Spring Cloud Config、携程Apollo、Nacos。Apollo架构特点本地应用有配置中心客户端可以定时同步配置如果配置中心宕机会使用缓存配置以保证正常运行。第三篇通讯与数据图7微服务通信方式关于通讯方式市面上主要是两种远程调用方式RESTfulHTTP使用HTTPJSON。优点是轻量、跨语言缺点是性能稍低Spring Cloud使用。RPC远程过程调用。优点是高性能缺点是耦合度高Dubbo使用。特性RESTfulRPC协议高层级HTTP四层TCP / 自定义协议消息格式JSON文本二进制序列化如Protobuf性能较低较高跨语言强较弱图8分布式事务与CAP理论分布式系统来说P分区容错性是不能放弃的所以我们通常需要在C一致性和A可用性之间权衡。CAP理论一致性、可用性、分区容错性三者只能取其二。BASE理论基本可用、软状态、最终一致性。这是对CAP中AP方案的补充。分布式事务解决方案TCC模式Try预留-Confirm确认-Cancel撤销。通过补偿机制实现最终一致性。示例Bob向Smith转账先在Try阶段冻结资金Confirm阶段执行转账Cancel阶段解冻。消息队列通过MQ确保消息可靠到达实现最终一致性。第四篇高可用与稳定性图9断路器熔断、降级、限流、隔离面对巨大的突发流量大型公司必须有一套自我保护机制。熔断像电路保险丝当请求失败率达到阈值自动断开服务防止故障蔓延。隔离将服务和服务隔离防止一个服务挂了导致雪崩。限流单位时间内只允许一定数量用户访问。降级当系统负载过高时关闭非核心服务如评论、积分保证核心交易流程。断路器的三个状态关闭正常访问错误数超阈值后变为打开。打开直接返回错误不调用实际服务。半开一段时间后放行部分请求测试如果成功则关闭断路器。图10链路监控APM在微服务架构中一次请求可能贯穿多个服务如果出错了如何快速定位这就需要全链路监控。核心原理Trace ID一次请求全局唯一的ID。Span ID每跨越一个服务生成一个新的Span ID并记录父Span ID。当请求进入Web容器时会创建Tracer和Spans。通过把这些Span放到后端服务调用链会动态生成调用链从而直观地看到哪个环节延迟最高。主流工具SleuthZipkinSpring Cloud、SkyWalking、CAT点评、鹰眼阿里。图11监控预警体系一个可靠的监控预警体系对微服务运行至关重要。监控一般分为以下层次基础设施监控CPU、内存、磁盘、网络。微服务监控Metrics吞吐量、响应时间、健康检查。日志监控典型的方案是ELKElasticsearch Logstash Kibana。图12发布策略蓝绿发布与金丝雀发布服务发布不仅要快还要稳蓝绿发布蓝环境老版本和绿环境新版本并存。流量从蓝环境一刀切到绿环境。优点是切换简单缺点是资源需要两倍。金丝雀发布先让1%的流量访问新版本验证没问题后逐步扩大到5%、10%、100%。优点是风险平滑缺点是需要精细化流量控制。第五篇总结与解决方案主流微服务架构方案对比目前市面上主流的微服务解决方案有以下几种功能组件Spring Cloud NetflixSpring Cloud AlibabaDubbo注册中心Eureka已停更NacosZookeeper / Nacos配置中心Spring Cloud ConfigNacos ConfigApollo / 无服务调用Feign RibbonFeign /Dubbo RPCDubbo RPC熔断/限流Hystrix已停更SentinelSentinel / 无API网关Zuul / GatewaySpring Cloud GatewayHigress / 无社区活跃度较低维护模式高高总结为什么要用微服务优点服务足够内聚、代码容易理解。开发效率高小团队2-5人可以单独开发维护。松耦合独立部署。允许技术多样性不同的服务可以用不同的语言开发。缺点带来了分布式系统的复杂性网络延迟、分布式事务。运维成本高需要管理几十甚至上百个服务。测试复杂性增加。接口调整成本高。什么组织适合使用微服务康威定律设计系统的组织其产生的设计等同于组织之间的沟通结构。如果你的团队结构是跨职能的小团队微服务天然适合你。生产力拐点当团队人数规模达到百人左右单体应用的内耗会显著降低生产力此时是引入微服务的最佳时机。