第 10 周 作业 2

用户头像
Yangjing
关注
发布于: 2020 年 11 月 29 日

微服务:服务本身的设计、维护以及治理



微服务重点在于服务的模块拆解、设计、维护、治理。而不是框架的使用、框架的远程调用、RPC远程调用(入门的内容)。

服务本身要做好(划分、设计),再选择一个技术工具(框架、技术)。



微服务是用来解决巨无霸应用系统带来的问题:

  • 编译、部署困难

  • 代码分支管理困难

  • 数据库连接耗尽

  • 新增业务困难



解决的方案就是拆分、将模块独立部署,降低系统耦合性

纵向拆分:将一个大应用拆分为多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的 Web 应用系统。

横向拆分:将复用的业务拆分出来,独立部署为微服务,新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务框架

SOA web service 是最老、最原始的微服务框架。包含了服务提供者、服务请求者、注册中心3个角色。

缺点:

  • 臃肿的注册和发现机制

  • 低效的 XML 序列化手段

  • 开销较高的 HTTP 远程通信

  • 复杂的部署与维护手段

难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。



微服务框架除了注册和发现机制、服务调用标准功能、还需要下面功能:

  • 负载均衡:对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问,使服务提供者集群实现负载均衡

  • 失效转移:微服务框架需要支持服务提供者的失效转移机制,以实现服务高可用

  • 高效的远程通信:基于长连接、私有定制的协议、二进制的序列化方式、减少数据传输,提高通信速度

  • 对应用最少侵入:微服务也需要渐进式的演化。微服务模块本身需要支持集中式部署、也可以分布式部署

  • 版本管理:服务升级、接口变更不受影响。服务的版本。



微服务框架 Dubbo 架构

  • 服务消费者

  • 服务提供者

  • 服务注册中心



微服务 落地实践的策略与思路



Service Mesh 服务网格

Service Mesh 是一个基础设施层,用于处理服务间的通信,通常表现为一组轻量级网格代理,它们与应用程序部署在一起,而对应用程序透明。



Service Mesh 的 Sidecar 模式



微服务架构实践

微服务架构落地

  • 业务先行,先理顺业务的边界和依赖,技术是手段而不是目的

  • 先有独立的模块,后有分布式的服务

  • 业务耦合严重,逻辑复杂多变的系统进行微服务重构要谨慎

  • 要搞清楚实施微服务的目的是什么,业务复用?业务开发边界清晰?分布式集群提升性能?



命令与查询职责隔离(CQRS):在服务接口层面将查询(读操作)与命令(写操作)隔离,实现服务层的读写分离。

  • 更清晰的领域模型

  • 针对读写分别优化,实现更好的性能

  • 查询服务不会修改数据,更好的保护数据



事件溯源

将用户请求处理过程中的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储。

  • 利用事件溯源,可以精确复现任何用户状态,进行复核审计

  • 利用事件溯源,可以有效监控用户状态变化,并在此基础上实现分布式事务



断路器

当某个服务出现故障,响应延迟或者失败率增加,继续调用这个服务会导致调用请求阻塞,资源消耗增加,进而出现服务失效,这种情况下使用断路器阻断对故障服务的调用。



服务重试及调用超时

上游调用者的超时时间要大于下游超时时间之和。



最重要的是需求

  • 需求

  • 价值

  • 原则

  • 最佳实践

  • 选择对应工具

微服务网关的技术架构

微服务网关的作业

  • 统一接入:高性能、高并发、高可用、负载均衡

  • 安全防护:防刷控制、黑白名单

  • 协议适配:http、dubbo

  • 流量管控与容错



微服务网关是微服务中的消费者。



网关管道技术

网关本身没有什么业务,主要职责是各种校验与拦截,这些职责可以通过管道技术连接起来

实现管道技术的责任链设计模式



Flower 异步网关与异步微服务框架

  • 利用 Servlet3 实现异步网关

开放平台网关

  • API 接口:是开放平台暴露给合作者使用的一组 API ,其形式可以是 RESTful、WebService、RPC 等各种形式

  • 协议转换:将各种 API 输入转换成内部服务可以识别的形式,并将内部服务的返回封装成 API 的格式。

  • 安全:身份识别、权限控制,开放平台还需要分级的访问带宽限制,保证平台资源被第三方应用公平合理使用,也保护网站内部服务不会被外部应用拖垮。

  • 审计:记录第三方应用的访问情况,并进行监控、计费等。

  • 路由:将开放平台的各种访问路由映射到具体的内部服务。

  • 流程:聚合内部服务。



目前互联网上使用最多也是最安全的是:开放授权协议 OAuth2.0 的授权码。

例如网易云音乐使用微信账号登录。

  1. Client 是网易云音乐的APP。

  2. 用户点击使用微信登录,APP 调起登录的授权界面 User-Agent,用户(也就是 Resource Owner )点击同意授权,User-Agent 将用户授权信息提交给授权服务器(Authorization Server 微信的授权服务器),授权服务器返回用户同意的授权码(Authorization Code),授权页面再将授权码返回给网易云音乐。

  3. 网易云音乐用授权码到 Authorization Server 进行登录验证,拿到用户的 Access Token。

领域驱动设计 DDD

领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现,也就是说,设计好了领域对象,也就设计好了业务逻辑实现。和事务脚本的贫血模型相对应,领域模型被称为充血模型。



领域是一个组织所做的事情以及包含的一切,通俗地说,就是组织的业务范围和做事方式,也是软件开发的目标范围。

领域驱动设计就是从领域出发,分析领域内模型及其关系,进而设计软件系统的方法。



子域:通常再把领域拆分为多个子域。如用户、商品、订单、物流等。

限界上下文 = 子域



实体

领域对象模型也被称为实体,每个实体都是唯一的,具有一个唯一标识,一个订单对象是一个实体,一个商品对象也是一个实体,订单ID和商品ID是它们的唯一标识。实体可能发生变化,比如订单状态,但是它们的唯一标识不会改变。

实体设计是 DDD 核心所在,首先通过业务分析,识别出实体对象,然后通过相关的业务逻辑设计实体的属性和方法。这里最重要的是要把握住实体的特征是什么,实体应该承担什么职责。



值对象

一个特点是创建之后不能再改变了。比如地址,如果改变了,就是一个新地址了;而一个订单的实体则可能发生改变。

通过传递值对象,解决方法中 getById、getByName、getByAge,参数应该改成一个值对象。



聚合

一个关联对象的集合。将其作为一个单元来处理数据更改。



领域、子域、界限上下文、上下文映射,这些是 DDD 的战略设计。

实体、值对象、聚合、事件溯源是 DDD 战术设计。



多搞事情,做失败了比不做好,实在担心就硬上,失败了会带来思考,逃避了只会给自己打上一个逃兵的烙印。

发布于: 2020 年 11 月 29 日阅读数: 16
用户头像

Yangjing

关注

还未添加个人签名 2017.11.09 加入

还未添加个人简介

评论

发布
暂无评论
第10周 作业2