ARTS Week 4

ARTS Week 4


图片

凡是过往,皆为序章。 – 莎士比亚


Algoithm

直接求和

概述

求 1+2+…+n ,要求不能使用乘除法、for、while、if、else、switch、case等关键字及条件判断语句(A?B:C)。

分析

因为禁用了 乘除 和循环等特性,所以能够使用的就是递归的方式。同时不能使用 if 那么就需要进行 前置判断。

  • 如何停止递归: n!=0
  • 递归范式如何: n+fun(n-1)

代码

# method 1
# 递归方式 ,最后会判断其 是否为 0。如果为 0,那么就不会 进行递归。
class Solution:
    def sumNums(self, n: int) -> int:
        # 判断其是否为0。
        return n != 0 and n + self.sumNums(n - 1)

# 内置函数
class Solutionm:
    def sumNums(self, n: int) -> int:
        return sum(range(n + 1))  # 这里需要注意的是需要使用 num+1

Review

为什么从 Falsk to FastAPI

概述

文章讲述了使用API作为信息收集、模型计算。对于实时性、高并发有很强的要求。同时对了Flask 和 FastAPI 框架的异同。
FastAPI 框架是使用 epoll 异步方式 提升更加高的并发性,对于异步IO 操作能够有很强的并发性能,但是因为 GIL CPU 计算类型还是需要使用其他框架
进行。
Flask 是一个标准的 同步io 框架,但是可以通过 monkey 补丁,使其具有异步性能提升,但是对于大多数人来说,还是比使用Linux 系统 原生 epoll 方式,
有很大的弊端,所以相比较 FastAPI 还是有很大的差距的。

思考

  • 尽可能使用系统底层支持的 异步 开放接口,这样对于系统稳定和系统设置,确实会有非常不错的体验!
  • 引入其他依赖,一方面会导致系统的耦合性,另一方面有造成其他意想不到的情况,还需要考虑兼容问题。
  • 从业务角度看待选型问题,这样更加能够比较平衡的方式实现较为良好的方式。

Tip

Hystrix 熔断、限流机制

概述

  • Hystrix 熔断机制,

    • 简单的介绍了一下内部算法,设置和参数,但是个人感觉差距还是很大,
    • 比如:在分布式中,某一个 rpc 服务,会有多个节点 A/B/C
      那么如果仅仅是 A节点出现了问题,B/C节点没有问题,那么是否可以识别到?
    • 文章显示是只有其 rpc 服务 整体的监控和熔断,而没有对于分布式 单节点出
      问题的总结和看法。对于微服务架构,需要实现的是能够快速确定问题,保证问题不会扩大,同时快速判断问题根源的问题。
  • 限流算法,计数器、令牌桶算法、漏斗

类型实现方式优势缺点
计数器同时redis/mysql 实现对于请求的实时统计简单快速依赖第三方
漏斗算法漏斗大小固定,只会从漏斗下方正常请求,其他的请求,放入漏斗、直接返回固定数值能够保证后端稳定分布式限流不怎么适合
令牌算法令牌生成速率恒定,有令牌请求通过,无令牌屏蔽通漏斗算法
  • 熔断与恢复
    • 熔断 设置级别设置等。
    • 恢复 是会定时监控其,服务是否正常,如果正常,那么正常反馈。

思考

  1. 趋势

    1. 微服务架构能够快速实现业务开发,但是因为其 “微” 导致,发现问题、限制问题、解决问题 需要快速实现,那么就需要对于 日志、监控、限流、熔断、恢复、
      报警 等需要能够快速响应,确定问题。同时重点是 日志、限制问题、确定问题、解决问题 这几个方面。
    2. 日志 微服务的日志 需要的是 全链路 监控,是一个完整的 请求、中间、返回 。不论中间经历过哪些,都是需要能够找到完整日志。
    3. 限制问题,当服务某一个节点发生问题后,需要快速判断其影响范围,同时报警、自动重启等操作,这样快速实现系统的自恢复。如果问题没有得到有效解决,
      那么就需要快速通知到负责人,修复。
    4. 确定影响范围,因为 微服务架构 导致 可能会产生 蝴蝶效应 ,所以 影响范围需要提前确定,同时制定预警方案。
  2. 准确

    1. 以后的数据化时代到来,准确越来越重要,不论是AI 等其他方式,都是为了将 重复低价值劳动 教给机器,而有时间可以做更加难度的事情。

Share

大厦基石

概述

文章主要描述了依托于 冯·诺依曼体系结构 是现在的科技之父,开创了现在的基石。同时现在反过来进行思考,能够快速找到核心的模块,只定义核心要素,
同时又不会缺少其可扩展性,让系统既保持了简单,又保证了可扩展性。

思考

  1. 业务架构

    1. 核心是为了能够解决业务问题,同时也需要考虑后期的可扩展性。
    2. 架构需要能够抽离业务核心、抽象业务形态,这样才可以保证系统的后期扩展。
  2. 可扩展性

    1. 底层核心实现后,同时也需要考虑后期的可扩展性,不仅仅在日志等,同时也需要考虑,业务复杂度,增加的设计自模式。是否可以便捷快速接入新的业务?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值