- 微服务2.0:
使用了熔断、限流、降级等服务治理策略,并配备完整服务工具和平台。
- 微服务3.0:
Service Mesh将服务治理作为通用组件,下沉到平台层实现,应用层仅仅关注业务逻辑,平台层可以根据业务监控自动调度和参数调整,实现AIOps和智能调度。
微服务架构
先决条件
- 快速的环境提供能力:
依赖于云计算、容器技术,快速交付环境。
- 基本的监控能力:
包括基础的技术监控和业务监控。
- 快速的应用部署能力:
需要部署管道提供快速的部署能力。
- Devops文化:
需要具有良好的持续交付能力,包括全链路追踪、快速环境提供和部署等,还需要快速的反应能力(对问题、故障的快速响应),开发和运维的协同工作。
此外,根据康威定律和逆康威定律(技术架构倒逼组织架构改进),组织架构也是一个很关键的因素。对应于微服务架构,组织架构需要遵循以下原则:
-
一个微服务由一个团队维护,团队成员以三人为宜。
-
单个团队的任务和发展是独立的,不受其他因素影响。
-
团队是功能齐全、全栈、自治的,扁平、自我管理。
基础设施
微服务的推行需要依赖于很多底层基础设施,包括提供微服务的编译、集成、打包、部署、配置等工作,采用PaaS平台解决微服务从开发到运行的全生命周期管理,同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。
- 最基本的基础设施
- 进程间通讯机制:
微服务是独立进程的,需要确定之间的通讯方式。
-
服务发现+服务路由: 提供服务注册中心,服务提供者和消费者通过服务发现获取服务的信息从而调用服务,实现服务的负载均衡等。
-
服务容错:
微服务架构中,由于服务非常多,往往是一个服务挂了,整个请求链路的服务都受到影响,因此需要服务容错,在服务调用失败的时候能够处理错误或者快速失败,包括熔断、fallback、重试、流控和服务隔离等。
- 分布式事务支持:
随着业务拆分为服务,那么有时候不可避免的就是跨服务的事务,即分布式事务的问题。
原则是尽量避免分布式事务,如果无法避免那么可以使用消息系统或者CQRS和Event Sourcing方案来实现最终一致性。
如果需要强一致性,则有两阶段提交、三阶段提交、TCC等分布式事务解决方案。
- 提升外部服务对接效率和内部开发效率
- API网关: 负责外部系统的访问,负责跨横切面的公共层面的工作,包括安全、日志、权限控制、传输加密、请求转发、流量控制等。
典型的网关功能即对外暴露一个域名xx.com,根据第一级目录做反向路由xx.com/user,xx.com/trade。
每一级目录,如user、trade对应一个服务的域名。
此外,API网关也可以有服务编排的功能(不推荐)。
- 接口框架: 规范服务之间通讯使用的数据格式、解析包、自解释文档,便于服务使用方快速上手等。
- 提升测试和运维效率
- 持续集成: