写点什么

Week 10 学习总结

用户头像
wyzwlj
关注
发布于: 2020 年 08 月 11 日

一、微服务

1、为什么使用微服务?

    1)单体巨无霸系统带来的问题

        a. 编译、部署困难

        b. 代码分支管理困难

        c. 数据库连接耗尽

        d. 新增业务困难

    2)拆分,将大应用拆分为多个小应用

        a. 横向拆分:将公共的业务拆分出来,复用于其他业务

        b. 纵向拆分:将大应用拆分多个小应用

二、微服务架构落地的支撑--微服务框架

1、微服务框架的起源--Web Service

    1)三个角色:

        a. Service Provider:服务提供者

        b. Service Requester:服务消费者

        c. Service Broker:服务注册中心

    2)不足之处:

        a. 臃肿的注册于发现机制

        b. 低效的XML序列化手段

        c. 开销相对较高的HTTP远程通信

        d. 复杂的部署与维护手段

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

2、微服务框架中的关键点

    1)服务的注册与发现

    2)服务间的远程调用

    3)失效转移--高可用

        a. 服务集群化部署,实现服务的高可用

        b. 调用某个服务实例失败时,调用者需要尝试换一个服务实例

    4)负载均衡

        a. 服务集群化部署后,需要使用负载均衡的访问方式

        b. 调用者按照负载均衡策略访问服务实例

    5)高效远程通信--通信协议

        a. HTTP协议相对低效,需要自己实现一套高效的通信协议

    6)对应用最少侵入

        a. 业务开展服务化的过程是渐进的,所以微服务框架要减少对业务的影响,方便业务的演进

    7) 服务的版本管理

3、微服务框架案例分析--Dubbo



4、Service Mersh

    1)微服务框架存在的问题

        a. 服务的调用者需要自己负责服务的发现和调用(通过代理对象)

        b. 服务的调用者需要自己实现失效转移处理(通过代理对象)

        c. 服务的调用者需要自己实现负载均衡的调用处理(通过代理对象)

        d. 服务的调用者需要自己决定远程调用服务的方式和使用协议(通过代理对象)

        -->服务调用方为了调用服务,需要做很多的事情,而且这些事情对不同的调用方而言,是相似的、重复的!

    2)Service Mersh做的事情

        a. Service Mersh构建了一个用于服务间通信的基础设施层,用于处理服务间的通信

        b. 相当于把代理对象抽离出来,构成了一个中间层,原来代理对象做的事情,都交给了Service Mersh

        c. Service Mersh的Sidecar模式



三、如何落地微服务架构

1、微服务落地的关键点,不是技术,而是要理顺业务,梳理业务的边界

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

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

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

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

    -->倒三角模型:

2、微服务落地时的一些关注点

    1)事件溯源

        a. 将用户的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储

        b. 可复现用户的状态变化,进行复核审计

        c. 可在此基础上实现分布式事务

    2)断路器

        a. 阻断对故障服务的调用,避免响应延迟或失败率增加,导致请求的阻塞和资源消耗

    3)服务重试&调用超时

    4)分布式链路追踪

3、微服务落地时的一些实践

    1)CQRS

四、微服务网关

1、基于网关的微服务架构

2、网关的作用

    1)统一接入

    2)流量管控与容错

    3)协议适配

    4)安全防护

3、网关中的技术

    1)网关管道技术:责任链模式

    2)异步网关:Servelrt3

4、网关分类

    1)开放平台网关

    2)安全网关

五、微服务发展小结

1、单体应用->微服务:解决发布、部署困难的问题

2、微服务->平台化:构建通用服务、服务复用

3、平台化->中台化:微服务定义了业务规范。业务系统依赖微服务,实现具体的业务

六、领域驱动设计--DDD

1、为什么需要DDD

    1)软件只有需求分析,没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一致性

    2)功能特性并不是按照领域模型内在的逻辑设计,而是按照个色人等自己的主观想象设计

    3)以上两点导致随着需求的零散开发和变更,项目变的越来越复杂和难以维护

2、DDD是什么

    1)传统开发模式:事务脚本型、面向过程的编程;DDD:领域模型、面向对象的编程

    2)贫血模型 VS 充血模型

3、怎么做DDD

    1)领域:明确产品要做的事情、范围、边界

    2)子域:整个领域要做的事情太多、太大,需要拆分,拆分成多个子域

        a. 如何划分子域?划分的规则?

    3)界限上下文

        a. 和子域具有一对一的关系,用来控制子域的边界        b. 在界限上下文划定的边界中,任何领域对象都具有唯一的特定含义,不存在二义性

    4)上下文映射图:描述子系统或模块之间的交互合作

    5)实体

    6)值对象

        a. 实体 VS 值对象:对实体而言,属性值相同并不表示是同一个对象,一定需要通过ID值进行区分;对值对象而言,属性值相同一定表示同一个对象

    7)聚合

4、DDD相关架构

    1)分层架构

    2)六边形架构

5、DDD战略设计与战术设计

    1)战略 VS 战术

        a. 领域、子域、界限上下文、上下文映射图,这些是战略设计        b. 实体、值对象、聚合、CQRS、事件溯源,这些是战术设计

    2)战略的作用

       a. 通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要



        



用户头像

wyzwlj

关注

还未添加个人签名 2018.05.02 加入

还未添加个人简介

评论

发布
暂无评论
Week 10学习总结