简介

◇微服务是一种架构风格,由Martin Fowler与James Lewis于2014年提出;
◇微服务方式是使用一套小服务来开发单个应用,每个服务运行在自己的进程中(每个服务可看作一个小的应用),并使用轻量级机制通信,通常是HTTP API,这些服务能够通过独立的自动化部署,可以分别使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理;
◇微服务理念:有效拆分服务,提供一套统一基础架构使得各个微服务能独立的部署、运行、升级,具有轻量级的通信机制进行通信,在结构上松耦合而在功能上表现为一个整体,实现应用的敏捷开发与部署;
◇服务拆分原则:当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过2个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块;
◇微服务相关开发工具:
(1)Spring Cloud为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包;
(2)Dubbo
(3)Dropwizard(关注单个微服务的开发)
◇服务间通信方式:
(1)REST,同步方式
(2)RPC,同步方式
(3)消息队列,异步方式

单体架构相对微服务架构的缺点

●代码与模块越多,逻辑复杂性越高越难理解,越难解决遇到的问题;
●项目部署与启动速度逐渐变慢,修复局部模块问题需要重启整个项目使问题处理速度变慢;
●新技术重构与升级项目的成本逐渐变高,新加模块使用新技术受限制,加入数据分析与监控容易出现性能瓶颈;
●不利于按各模块需求伸缩资源(CPU/内存/数据库);
微服务架构相对单体架构的缺点
△维护项目变多,处理分布式的场景变多,需要更强的故障处理机制机制;

重要部件

●API网关
(1)后台服务的聚合,在前端与后台之间提供统一的服务入口,让微服务对前端透明;
(2)提供安全、过滤、流量控制等API管理功能;
●服务发现,分布式管理各服务链接信息的注册与更新(例:Zookeeper、Eureka、Consul、Etcd);
●故障处理
a.减少故障机率
(1)监控,各服务设置监控指标与提供状态,采集器采集,UI呈现(例:RedisExporter、MySQLExporter、Prometheus、Grafana);
b.降低故障对整体的影响
(1)降级,当某服务的下游非核心服务停止工作,则暂时将其关闭,保证核心业务不中断;
(2)熔断,为了避免每次请求都等待超时导致链路资源长时占用进而导致请求堆积,每个服务对其下游服务使用熔断机制快速返回失败并通过定时健康检查自动恢复;

(3)限流,服务面对瞬时流量过大情况的自我保护,推荐区分服务的限流策略,可应对某个服务由于代码问题发起的大量请求; c.提供故障排查效率 (1)链路跟踪(例:Dapper、Zipkin),查看请求经过哪些服务节点及各自的响应时长 (2)日志分析,各服务日志采集与检索支持,通常用ELK实现; ### 应用实例 ■配置管理服务 (1)配置管理服务集中管理其他各微服务在各运行环境下的配置,配置支持实时动态修改与自动更新到其他各微服务,支持版本控制与内容审计; (2)每个从配置管理服务请求自己的配置并缓存本地; (3)经典案例:Apollo、Spring Cloud默认使用Git存储配置内容;