写点什么

【week10】总结

用户头像
chengjing
关注
发布于: 2020 年 08 月 12 日

回顾上周作业:


  1. JVM 垃圾回收

算法:可达性算法,三种清理算法,分代回收算法

垃圾回收器:四种 串行,并行,并发,G1,ZGC

2.秒杀挑战

对现有系统的影响,短时间大量并发请求,网络带宽,直接下单

独立系统 动态内容静态化 CDN 动态生成随机下单页面 Url

重点:脱颖而出的一定不是大路货,一定要找到问题的关键,一定不在大多数的方案里;靠学习只能维持不能淘汰,一定要找新的关键点,方案的关键点

老师分享的自己的案例:缩减 app 大小,通过分析最近半年提交的源码,按从大到小排序,找到相关部门处理

微服务


阿里早期微服务架构重构

多个模块,单体应用,一个大的 war 包

编译部署困难,一个包 3.2G;各个模块的依赖配置项复杂

代码分支管理困难:复用代码模块多个团队共同维护修改,解决代码冲突,纠结在一起,故此失彼

数据库连接耗尽:每个模块都需要连接数据库

新增业务困难:在一个关系乱麻般的系统中增加新业务

解决方案: 拆分

web service 方案:wsdl uddi soap

效率底下:http, xml

微服务:服务发现,协议转换,api 网关,其他 失效转移 负载均衡 加权轮询等(框架内解决不用 lvs)

高效的远程通信:对应用最小的侵入,服务的使用者感觉不到微服务的存在(服务代理,基于接口实现)

版本管理:快速变化的需求,版本升级,多版本同时运行(调用时带上版本号)

微服务框架:Dubbo;框架并不重要

消费者 注册中心, 提供者

容器启动-》注册服务


服务接口-》接口代理-》框架客户端

查找服务提供者列表 如果没有,则到注册中心里查找

负载均衡模块,算出一台服务器 -》 远程通讯调用

提供者:查找接口类,调用类方法(传参数),调用完成后,返回 class 保证成响应,返回

拿到响应,反序列化 class,返回接口应用程序


失效转移:很少访问的也需要集群

高效通信:长连接,二进制序列号协议

最少侵入:依赖一个接口包


支持版本管理:一个服务升级后,原来的版本保留半年


service mash

服务网格 消费者依赖的 sdk 包分离成一个独立组件,应用程序和 service mash 通信

client:

注册,查找,调用

client-》service mash :查找,调用

sidecar 模式:


架构如何落地:


  1. 业务先行, 理顺边界和依赖,发现真正的需求

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

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

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


不要用战术上的勤奋掩盖战略上的懒惰


相关概念:

CQRS,读写操作分离,实现服务层的读写分离。

更清晰的领域模型,针对读写分别优化,实现更好的性能

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


读:缓存;写:消息队列

事件溯源:所有写操作都记录到日志中,并按照时间序列进行持久化存储。可精确复现任何用户状态,进行复核审计

可以监控状态变化,并在此基础上实现分布式事务(记录全部正确完成的事务)

断路器:某个服务出问题时,响应延迟,失败率增加等,可以断路处理,半开,或全闭

最重要的需求:

needs,values,principles,practices,tools


rpc:协议原理,远程过程调用,是一个底层协议及框架


形形色色的架构师:

mbta 测试-》n 值,s 值

宏观的,抽象的,整体的;具体的,

按作用:设计型;救火型;布道型;Geek 型架构师


DDD

领域模型:

各种概念和细节

真正的关键点是什么


不断变更

各处代码实现,修修补补

有些越来越大,有些越来越小

只有需求分析,没有设计,没有一个统一的领域模型维持其内在的逻辑一致性

代码应该放在哪里

有哪些模块,模块之间的关系如何


需求不断延期,线上 bug 不断,不断延期;

举例遥控器:密密麻麻的按键,堆功能。


事务脚本:

控制层,服务层,DAO 没有对象,没有模型,


通过业务自己完成,合同类

事务脚本里合同是没有任何方法的,只是一个数据集


领域模型里每个对象本身要完成本相关的计算


有几种策略,就有几种策略类。

计算合同:


让对象处理自己的相关业务,拥有自己的成员变量


而不是脚本方式的把方法和对象进行分离


本质上就是面向对象设计


贫血模型《》充血模型


事务脚本方式为贫血模型

领域模型包含了对象的数据和计算逻辑,是真正的对象


设计不好无法落地


DDD 的出现是用来解决这个问题的


战略设计

核心是领域,就是组织包含的一切,也是软件开发的目标范围

拆分成多个子域:通过内聚性,低耦合

如何划分子域


跟财务相关?


子域就是微服务:子域分析清楚了,边界清楚了,

那么服务的边界就划分清楚了


限界上下文:任何领域对象都只表示特定与该

边界内部的确切含义。限界上下文和子域具有一对一的关系,用来控制子域的边界,保证子域内的概念统一性


不同的限界上下文,也就是不同的子系统,模块之间会有各种交互


可以只使用战略设计,用来划分微服务


战术设计:


实体:唯一的,有行为的。识别对象,承担的职责

值对象:没有行为,特定是不变性


聚合:关联对象的集合


这个节奏,关键点需要把控。


DDD 战略设计:领域建模

DDD 战术设计:样例代码


按照战略与战术设计,将重构开发和迭代像结合


用户头像

chengjing

关注

程靖 2018.06.06 加入

还未添加个人简介

评论

发布
暂无评论
【week10】总结