微服务架构设计原理

1.传统单机架构到服务化架构

1.1企业架构

J2EE企业级软件架构

• Web层: 负责与用户交互或者对外提供接口
• 业务逻辑层:为了实现业务逻辑而设计的流程处理和计算处理模块
• 数据存取层:将业务逻辑层处理的结果持久化已待后续查询,为维护领域模型中对象的生命周期

典型的二八原则,将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里,通过配置的模式提供给应用程序访问,应用程序实现20%的专用逻辑,并通过配置的形式来访问应用服务器提供的模块化组件.应用服务器提供对象关系映射服务,数据持久服务,事物服务,安全服务,消息服务等通过简单的配置即可在应用程序中使用.

对应职能团队分为UI交互研发团队,后台业务逻辑处理团队,数据存取ORM团队,DBA团队.

SOA服务化

• 良好的对外接口,通过网络协议对外提供服务.服务之间表现为松耦合性
• 单个服务内部结构和实现在发生改变时,不影响整个流程对外提供服务.只要对外接口保持不变,则改变服务内部的实现机制对外是透明的
• 通信格式XML,后来被JSON取代
• 服务的可重用性
• SOA可以最大化使用内部和外部的公共服务

SOA实现方式:Web Service和 ESB.

Web Service的问题

• 依赖中心化的服务发现机制
• SOAP使用XML冗余大
• 服务化管理和治理设施不完善

ESB

功能职责

• 监控和控制服务之间的消息路由
• 控制可插拔的服务化的功能和版本
• 解析服务之间交互和通信的内容和格式
• 通过组合服务,资源和消息处理器来统一编排业务需要的信息处理流程
• 使用冗余来提供服务的备份能力

1.2 微服务

微服务,倡导将人间应用设计成多个可独立开发,可配置,可运行和可维护的子服务,通过使用RESTful风格的API形式来通信.

微服务真正目的是通过水平扩展解决传统单体应用业务增长遇到的问题,拆分后人员和项目责任单一,低耦合,高内聚.

• 职责单一的功能放在一个独立的服务
• 每个服务运行在单独的进程
• 每个服务有多个实例运行.运行在容器化的平台,可以平滑伸缩
• 每个服务有自己的数据存储.独立的数据,缓存,消息队列等
• 每个服务有独立的运营平台.每个服务高度自治,内部变化对外透明
• 每个服务可以根据性能独立地水平伸缩

单体应用的特点:

• 所有模块混合运行在同一个JVM进程中
• 可以对多个模块的整体水平扩展,无法对某个模块水平扩展
• 某个模块发生变化,所有模块需要编译打包上线
• 模块简单依赖不清晰,相互耦合

微服务架构和SOA一脉相承,也略有不同.

• 目的不同.SOA强调异构服务之间协作和集成.微服务目的是拆分,实现敏捷开发部署
• 部署方式不同.拆分成多个小服务,使用敏捷扩容,Docker实现自动化容器管理.SOA服务将多个服务打包在一起,部署在一个服务器上
• 服务粒度不同.微服务拆分粒度更细,职责单一.通过服务组合实现业务流程.SOA对粒度没有要求,通常是粗粒度的

微服务核心要点:

• 职能团队的划分
• 微服务的去中心化治理
• 微服务的交互模式.读者容错模式(接口改变的容错),消费者驱动契约模式,去数据共享模式(不允许共享数据来集成多个服务). - 微服务的分解和组合模式.拆分达到高内聚低耦合.灵活组装来满足各种业务需求.组合方式有:服务代理模式(典型的案例:平滑的系统迁移),服务聚合模式,服务串联模式,服务分支模式,服务异步消息模式,服务共享数据模式(反模式,用于单元化架构和遗留的整体服务)
• 微服务的容错模式. 舱壁隔离模式(微服务容器分组和线程池隔离),熔断模式,限流模式(计数器,令牌桶,信号量),失效转移模式(快速失败,切换到备份,重试)
• 微服务的粒度.微服务初衷职责单一拆到不可再拆.原则是可以合理排版底层的自服务来获得相应的组合服务,同时考虑团队人员分配.

共享数据集成的缺点:

• 服务之间除了接口契约,还有数据存储契约.
• 上游数据格式变化,导致下游出问题.
• 多个服务共享一个资源,资源的运维和职责不清.
• 多机房部署,考虑到路由,跨机房调用,难以实现服务自治.

1.3 服务化管理和治理框架

1.3.1 RPC

JDK RMI

• RMI采用JDK自带的专用序列化协议,不能夸语言
• 使用了底层的忘了协议,不如基于文本的HTTP可读,也不如HTTP被广泛认可和应用
• 开源框架的飞速发展,严重削弱了JDK资深技术的流行程度

Hessian及Burlap

• 适合传输较小的对象,对较大复杂的对象,无论在序列化方式上还是在传输通道上都没有RMI有优势

Spring HTTP Invoker

1.3.2 服务化

• Dubbo
• HSF
• Thrift
• Axis
• Mule ESB

1.3.3 微服务

1.3.3.1 Spring Boot

• 可以创建独立,自启动的应用程序
• 不需要构建War包并发布到容器中
• 通过Maven的定制化标签,可以快速创建应用程序
• 可以最大化地自动化配置Spring,而不需要热工配置各项参数
• 提供了产品化特点:性能分析,健康检查,外部化配置
• 全程没有XML配置,也不需要代码生成

1.3.3.2 Spring Cloud Netflix

Spring Cloud Netflix包括服务发现组件Eureka,容错性组件Hystrix,智能路由组件Zuul和客户端负载均衡组件Ribbon

• 服务在Eureka实例中注册,有Spring管理发现和调用
• 通过配置启动Eureka服务器
• Feign客户端通过声明的方式即可导入服务代理
• Zuul使用Ribbon服务实现客户端的负载均衡
• 通过声明的方式即可插入Hystrix的客户端
• 通过配置的方式可以启动Hystrix面板服务器
• Spring下可以直接配置Netflix组件
• Zuul可以自动注册过滤器和路由器,形成一个反响代理服务器
• Hystrix面板可以对服务的状态监控,并提供容错机制