架构演化
架构是适应业务场景而生,有什么业务就有什么解决方案,即架构。
单体架构,如MVC
SOA架构
- 面向服务,按服务拆分all in的大应用
- 技术实现
- ESB:企业服务总线 - 支持异构环境中的服务、 消息, 以及基于事件的交互, 并且具有适当的服务级别和可管理性
- XML:消息交换格式
- SOAP:通常使用HTTP交换XML格式的消息
- WSDL:使用xml描述服务的接口,协议和格式
- UDDI:基于xml的注册协议,用于发布wsdl
- Web Service:使用以上四种技术,跨平台跨语言的应用接口技术/服务通信技术
- 解决了
- 缺点
- ESB笨重复杂的组件,它主要解决不同技术架构应用方面的通信(服务注册与发现),使用XML格式
- 虽然实现了分布式和水平罗展,但是ESB确是中枢,整体还是中心化的
- 缺乏统一标准,厂商之间的解决方案很难切换
- 不适合云环境
微服务架构
- 有一种说法是微服务是SOA的变体或子集。我们可以这样理解,微服务的服务拆分粒度更小。soa解决复用的问题,微服务解决扩展的问题
- 特点
- 一套小服务
- 独立进程
- 轻量级通信协议
- 可独立部署
- 多语言&不同储技术
- 优点
- 拆分粒度小,业务单一和聚焦,服务复用和服务解耦
- 易于开发,测试,部署,运维。更好实现敏捷开发和DevOps开发运维一体化
- 方便引入新技术
- 按需伸缩
- 缺点
- 分布式代价:分布式事务,分布式锁,远程调用
- 协同代价:一个项目上线可能涉及到数十个应用,这些项目又是不同的团队维护
- 服务拆分需要很强的设计功力:拆分不好,服务就不能实现高内聚低耦合的要求
- 服务爆炸,管理困难。调用链路变长,请求时间变长,并且难以追踪
- 部署和运维困难
- 总结
- 可以看出优点也是缺点,一体两面。
- 拆分的粒度小:优点,服务复用,解耦。缺点,服务爆炸,调用链路变长,难以追踪,拆分不好服务就不能实现高内聚低耦合
- 单个服务易于开发测试部署运维,但是一个需求往往涉及众多服务,有时可达几十个,部署和运维困难也不简单。
- 服务拆分后面临分布式开销与问题,分布式锁,网络开销,分布式事务等等。
- 广义的微服务不仅是定义之内的技术实现,还需要解决落地的问题,比如自动化部署与运维
概念
- 微服务中心概念是服务
- 可以拆分为多个关注点
- 服务注册中心
- 服务列表
- 服务注册
- 服务发现
- 负载均衡
- 硬件负载均衡如F5
- 软件负载均衡
- 服务端负载均衡
- 客户端负载均衡
- 服务容错
- 限流
- 熔断
- 网关
- 统一接入:路由
- 协议适配
- 流量管控:限流
- 安全防护:统一鉴权
- 黑白名单:IP地址控制
- 长短连接支持
- 链路追踪
云原生,云服务