微服务架构
什么是微服务架构风格?
微服务架构风格是将单个应用程序实现为一组小服务的软件设计开发方法,每个小服务都运行在自己的进程中,并以轻量化的机制进行通信(基于HTTP或RPC)。这些小服务围绕业务功能构建,可以通过全自动化部署机制进行独立部署。这些小服务应用最少的集中化管理(去中心化),他们可以用不同的编程语言编写,也可以使用不同的数据存储技术。
关键特征:
- 服务解耦(区别于单体架构风格的逻辑解耦)
- 每个服务打成独立的包,独立发布部署
- 跨进程、跨网络
- 动态注册、动态发现
- 数据库独立
微服务架构设计:分布式框架+高可用设计
更多:
- 服务注册、发现
- 动态发现:负载均衡、请求路由
- 序列化、反序列化(通信、网络传输)
- 高可用:熔断、限流、重试、降级
- 运维/可观测性:故障注入、日志、监控、metrics
- 安全:身份认证、加密解密、访问控制
组织、流程、工具链、自动化基础设施…
为什么要微服务架构风格?
互联网应用的需求:大容量、高并发、弹性伸缩、快。
并不是所有的服务都适合微服务架构,微服务架构需要一定的门槛:
- Rapid Provisioning
- 快速申请资源,资源池、云
- Basic Monitoring / 高可用
- 日志服务、监控告警、服务调用链
- 熔断、限流、降级
- Rapid application deployment
- Deploy Pipeline、自动化
- Organizational shift(组织转变)
- DevOps Culture
微服务架构的关键特征
- 通过服务进行组件化(物理解耦)
- 围绕业务能力进行组织(康威定律)
- Products not Projects(驱动力&价值)
- 只能端点和哑管道(非总线式)
- 去中心化治理
- 去中心化数据管理(数据解耦)
- 基础设施自动化(依赖自动化)
- Design for failure(面向失败设计)
- 演进式设计(可独立替换)
微服务架构的优缺点
优势:
- 简单 - 门槛低、易于维护、已与开发
- 可独立部署 - 并行开发、独立发布部署、快速上线
- 可独立技术选择
- 创新
- 规模增长
缺点:
- 分布式系统 - 系统复杂度增加、故障概率增加、故障定位困难,影响可用性;额外的性能损失;事务一致性问题
- 服务多 - 部署、升级复杂度增加,工作量增加
启示:
- 如何选择:大容量、高并发、动态资源申请;业务变化快、小团队、敏捷;系统已具有一定规模,演进阶段时的选择…
- 主要是企业应用类软件领域,电商应用、内容订阅应用等
- 考量:组织架构、软件形态、软件发布方式、所处阶段、基础能力
- 如果你不能正确地构建大型单体应用,那么微服务也帮不了你
微服务架构的主要技术服务和组件
- 服务注册发现:Eureka,Dubbo,Consul,ZooKeeper,Etcd,Nacos
- 路由&负载均衡:Ribbon,Dubbo,HSF,DSF
- 分布式服务框架:REST,gRPC,HSF,Dubbo,Hessian,DSF
- 序列化/反序列化:Protobuf,Hessian2,JSON,kryo,FST,Avro,BSON
- 服务网关:Zuul,SpringCloudGateway,CSB,APIFabric
- 服务配置:Archaius,SpringCloudConfig,Consulconfig,Apollo,ACM
- 服务熔断:Hystrix,resilience4j,Sentine,DSF
- 链路追踪:SpringCloudSleuth,Zipkin,Htrace,Turbine,ARMs,SkyWalking,DV
- 日志服务:logback,ElasticSearch,DV
- 监控平台:Promethues,Kibana,grafana,Springbootadmin,DV
- 分布式事务服务:GTS,Seata,FMT
- 应用容器:Karyon,ali-tomcat,OpenAS