凡是过往，皆为序章。 -- 莎士比亚
求 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文章讲述了使用API作为信息收集、模型计算。对于实时性、高并发有很强的要求。同时对了Flask 和 FastAPI 框架的异同。 FastAPI 框架是使用 epoll 异步方式 提升更加高的并发性，对于异步IO 操作能够有很强的并发性能，但是因为 GIL CPU 计算类型还是需要使用其他框架 进行。 Flask 是一个标准的 同步io 框架，但是可以通过 monkey 补丁，使其具有异步性能提升，但是对于大多数人来说，还是比使用Linux 系统 原生 epoll 方式， 有很大的弊端，所以相比较 FastAPI 还是有很大的差距的。
- 尽可能使用系统底层支持的 异步 开放接口，这样对于系统稳定和系统设置，确实会有非常不错的体验！
- 引入其他依赖，一方面会导致系统的耦合性，另一方面有造成其他意想不到的情况，还需要考虑兼容问题。
- 从业务角度看待选型问题，这样更加能够比较平衡的方式实现较为良好的方式。
-
Hystrix 熔断机制，
- 简单的介绍了一下内部算法，设置和参数，但是个人感觉差距还是很大，
- 比如：在分布式中，某一个 rpc 服务，会有多个节点 A/B/C 那么如果仅仅是 A节点出现了问题，B/C节点没有问题，那么是否可以识别到？
- 文章显示是只有其 rpc 服务 整体的监控和熔断，而没有对于分布式 单节点出 问题的总结和看法。对于微服务架构，需要实现的是能够快速确定问题，保证问题不会扩大，同时快速判断问题根源的问题。
-
限流算法，计数器、令牌桶算法、漏斗
| 类型 | 实现方式 | 优势 | 缺点 |
|---|---|---|---|
| 计数器 | 同时redis/mysql 实现对于请求的实时统计 | 简单快速 | 依赖第三方 |
| 漏斗算法 | 漏斗大小固定，只会从漏斗下方正常请求，其他的请求，放入漏斗、直接返回固定数值 | 能够保证后端稳定 | 分布式限流不怎么适合 |
| 令牌算法 | 令牌生成速率恒定，有令牌请求通过，无令牌屏蔽 | 通漏斗算法 |
- 熔断与恢复
- 熔断 设置级别设置等。
- 恢复 是会定时监控其，服务是否正常，如果正常，那么正常反馈。
-
趋势
- 微服务架构能够快速实现业务开发，但是因为其 "微" 导致，发现问题、限制问题、解决问题 需要快速实现，那么就需要对于 日志、监控、限流、熔断、恢复、 报警 等需要能够快速响应，确定问题。同时重点是 日志、限制问题、确定问题、解决问题 这几个方面。
- 日志 微服务的日志 需要的是 全链路 监控，是一个完整的 请求、中间、返回 。不论中间经历过哪些，都是需要能够找到完整日志。
- 限制问题，当服务某一个节点发生问题后，需要快速判断其影响范围，同时报警、自动重启等操作，这样快速实现系统的自恢复。如果问题没有得到有效解决， 那么就需要快速通知到负责人，修复。
- 确定影响范围，因为 微服务架构 导致 可能会产生 蝴蝶效应 ，所以 影响范围需要提前确定，同时制定预警方案。
-
准确
- 以后的数据化时代到来，准确越来越重要，不论是AI 等其他方式，都是为了将 重复低价值劳动 教给机器，而有时间可以做更加难度的事情。
文章主要描述了依托于 冯·诺依曼体系结构 是现在的科技之父，开创了现在的基石。同时现在反过来进行思考，能够快速找到核心的模块，只定义核心要素， 同时又不会缺少其可扩展性，让系统既保持了简单，又保证了可扩展性。
-
业务架构
- 核心是为了能够解决业务问题，同时也需要考虑后期的可扩展性。
- 架构需要能够抽离业务核心、抽象业务形态，这样才可以保证系统的后期扩展。
-
可扩展性
- 底层核心实现后，同时也需要考虑后期的可扩展性，不仅仅在日志等，同时也需要考虑，业务复杂度，增加的设计自模式。是否可以便捷快速接入新的业务?