写点什么

第十周学习总结

用户头像
菲尼克斯
关注
发布于: 2020 年 08 月 13 日

一、微服务

1、单体应用的问题:

👉编译、部署困难。系统庞大之后,也许只修改了一行代码,就可能会需要编译相当长的时间。

👉代码分支管理困难。多个团队维护公共代码,冲突多。

👉数据库连接耗尽。

👉新增业务困难。新人不敢做事,老人加班加不完。

2、解决上述问题的方法:

👉拆分,独立部署,降低耦合性;纵向拆分(独立业务);横向拆分(复用业务)。

3、Web Service 的思想

👉服务请求者、服务提供者、注册中心(90 年代就出现的面向服务的体系架构)

👉Web Service 的缺点:臃肿的注册与发现机制;低效的 xml 序列化手段;开销相对较高的 http 远程通信、复杂的部署与维护手段

4、微服务框架要求

失效转移、负载均衡、高效的远程通信、对应用最少侵入、版本管理

5、Service Mesh 服务网格

👉Service Mesh 基础设施层

👉1、用简单的方式将请求发送给本地的 service mesh 实例 2、Service mesh 进行服务发现 3、Service mesh 将请求转发给目标服务

6、微服务架构落地

👉业务先行,技术是手段而不是目的

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

👉逻辑复杂多变的系统进行微服务重构要谨慎

👉实施微服务的目的是什么

👉命令与查询职责隔离

👉事件溯源

👉断路器

👉服务重试及调用超时:上游调用者超时时间要大于下游调用者超时时间之和

7、RPC 协议实现原理

👉通讯协议:网络通信协议(TCP、UDP)、编码传输协议(二进制、文本)

👉常见协议:定长协议、特殊结束符协议、变长协议(协议头+协议体)

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


👉网关的作用:统一接入、安全防护、协议适配、流量管控与容错

👉网关管道技术

👉异步网关、异步微服务

👉开放平台网关

👉开放授权协议 OAuth2.0

授权码模式(使用最多、最安全)

隐式授权

资源所有者密码凭据

客户端凭据


二、领域驱动设计 DDD

1、为什么需要 DDD

👉需求零散、不断变更

👉工程师各处寻找、修修补补

👉只有需求分析,没有设计

👉功能特性按照主观想象设计

2、贫血模型 VS 充血模型

设计好了领域模型对象,也就设计好了业务逻辑实现

3、领域

👉领域:软件开发的目标范围

👉领域驱动设计:从领域出发,分析领域内模型及其关系

👉子域

👉限界上下文:通常对应一个组件、一个模块、一个微服务或者一个子系统

👉实体:领域模型对象。实体设计是 DDD 的核心。

👉DDD 分层架构、DDD 六边形架构

👉战略设计(领域、子域、限界上下文、上下文映射图)、战术设计(实体、值对象、聚合、CQRS、事件溯源)


三、架构师

👉设计型架构师(一般意义)、救火型架构师、布道型架构师、Geek 型架构师

👉夏尔巴人架构师(解决最具技术难度和挑战性的部分)、斯巴达人架构师(必胜的信念)

👉产品架构师、基础服务架构师、基础设施架构师


用户头像

菲尼克斯

关注

还未添加个人签名 2018.05.14 加入

还未添加个人简介

评论

发布
暂无评论
第十周学习总结