架构演化之SOA和微服务

架构演化

架构是适应业务场景而生，有什么业务就有什么解决方案，即架构。

单体架构，如MVC

SOA架构

• 面向服务，按服务拆分all in的大应用
• 技术实现
  • ESB：企业服务总线 - 支持异构环境中的服务、 消息， 以及基于事件的交互， 并且具有适当的服务级别和可管理性
  • XML：消息交换格式
  • SOAP：通常使用HTTP交换XML格式的消息
  • WSDL：使用xml描述服务的接口，协议和格式
  • UDDI：基于xml的注册协议，用于发布wsdl
  • Web Service：使用以上四种技术，跨平台跨语言的应用接口技术/服务通信技术
• 解决了
• 缺点
  • ESB笨重复杂的组件，它主要解决不同技术架构应用方面的通信（服务注册与发现），使用XML格式
  • 虽然实现了分布式和水平罗展，但是ESB确是中枢，整体还是中心化的
  • 缺乏统一标准，厂商之间的解决方案很难切换
  • 不适合云环境

微服务架构

• 有一种说法是微服务是SOA的变体或子集。我们可以这样理解，微服务的服务拆分粒度更小。soa解决复用的问题，微服务解决扩展的问题
• 特点
  • 一套小服务
  • 独立进程
  • 轻量级通信协议
  • 可独立部署
  • 多语言&不同储技术
• 优点
  • 拆分粒度小，业务单一和聚焦，服务复用和服务解耦
  • 易于开发，测试，部署，运维。更好实现敏捷开发和DevOps开发运维一体化
  • 方便引入新技术
  • 按需伸缩
• 缺点
  • 分布式代价：分布式事务，分布式锁，远程调用
  • 协同代价：一个项目上线可能涉及到数十个应用，这些项目又是不同的团队维护
  • 服务拆分需要很强的设计功力：拆分不好，服务就不能实现高内聚低耦合的要求
  • 服务爆炸，管理困难。调用链路变长，请求时间变长，并且难以追踪
  • 部署和运维困难
• 总结
  • 可以看出优点也是缺点，一体两面。
  • 拆分的粒度小：优点，服务复用，解耦。缺点，服务爆炸，调用链路变长，难以追踪，拆分不好服务就不能实现高内聚低耦合
  • 单个服务易于开发测试部署运维，但是一个需求往往涉及众多服务，有时可达几十个，部署和运维困难也不简单。
  • 服务拆分后面临分布式开销与问题，分布式锁，网络开销，分布式事务等等。
  • 广义的微服务不仅是定义之内的技术实现，还需要解决落地的问题，比如自动化部署与运维

概念

• 微服务中心概念是服务
• 可以拆分为多个关注点
  • 服务注册中心
    • 服务列表
    • 服务注册
    • 服务发现
  • 负载均衡
    • 硬件负载均衡如F5
    • 软件负载均衡
    • 服务端负载均衡
    • 客户端负载均衡
  • 服务容错
    • 限流
    • 熔断
  • 网关
    • 统一接入：路由
    • 协议适配
    • 流量管控：限流
    • 安全防护：统一鉴权
    • 黑白名单：IP地址控制
    • 长短连接支持
  • 链路追踪

云原生，云服务