自从今年封了Docker镜像后，想下个镜像就很麻烦，所以记录下代理的配置 代理仓库：https://github.com/MetaCubeX/mihomo 安装 启动 如果CentOS装了GUI可以试试这个 mihomo-party，亲测可行，之前在Ubuntu、Debain等试的其他的都各自问题启动不了 其他 配置Docker（针对docker pull 因为其被systemd接管） 修改 /lib/systemd/system/docker.service，在[Service]下添加 Environment=”HTTP_PROXY=127.0.0.1:7890″ Environment=”HTTPS_PROXY=12.0.0.1:7890″ 刷新并重启 systemctl daemon-reload systemctl restart docker 查看docker信息 docker info 完
设计模式这块，需要记一下
牛顿二项式 牛顿二项式（Newton’s Binomial）是一个数学公式，通常用于展开多项式的幂。这个公式由英国科学家伊萨克·牛顿（Isaac Newton）首次提出，并用于处理二项式系数的幂展开。牛顿二项式公式如下： 这个公式在组合数学、概率论、微积分等数学领域广泛应用。它不仅用于数学计算，还在物理学、工程学和计算机科学等各个领域中有实际应用。 e 常用等价无穷小 常用高阶导数 其中第7项，计算两个函数乘积的高阶导数，又称莱布尼兹公式 常用不定积分公式
转自 什么是UML？ UML是Unified Model Language的缩写，中文是统一建模语言，是由一整套图表组成的标准化建模语言。 为什么要用UML？ 通过使用UML使得在软件开发之前， 对整个软件设计有更好的可读性，可理解性，从而降低开发风险。同时，也能方便各个开发人员之间的交流。 UML提供了极富表达能力的建模语言，可以让软件开发过程中的不同人员分别得到自己感兴趣的信息。 Page-Jones 在《Fundamental Object-Oriented Design in UML》 一书中总结了UML的主要目的，如下： UML图有哪些？ UML图概览 什么是类图？ 类图中具体类、抽象、接口和包的表示法 UML类图中具体类、抽象类、接口和包有不同的表示方法。 1）在UML类图中表示具体类 具体类在类图中用矩形框表示，矩形框分为三层：第一层是类名字。第二层是类的成员变量；第三层是类的方法。成员变量以及方法前的访问修饰符用符号来表示： 2）在UML类图中表示抽象类 抽象类在UML类图中同样用矩形框表示，但是抽象类的类名以及抽象方法的名字都用斜体字表示，如图2所示。 3）在UML类图中表示接口 接口在类图中也是用矩形框表示，但是与类的表示法不同的是，接口在类图中的第一层顶端用构造型 <>表示，下面是接口的名字，第二层是方法，如图3所示。此外，接口还有另一种表示法，俗称棒棒糖表示法，就是类上面的一根棒棒糖（圆圈+实线）。圆圈旁为接口名称，接口方法在实现类中出现。 4）在UML类图中表示包 类和接口一般都出现在包中，UML类图中包的表示形式如图4所示。 ❝在类图中，常见的有以下几种关系。 ❞ 泛化（Generalization） 实现（Realization） 关联（Association） ❝自己买的车，想什么时候开就开。但是车是车，人是人，没有整体与部分的关系。 ❞ 聚合（Aggregation） ❝电脑有键盘才能输入信息，电脑是整体，键盘是部分，键盘也可以离开电脑，单纯的拿去敲。所以是聚合。 ❞ 组合（Composition） ❝鸟是整体，翅膀是部分。鸟死了，翅膀也就不能飞了。所以是组合。我们再看一下，下面的一组经典的聚合组合关系的例子。 ❞ ❝一个公司拥有多个部门，公司和部门之间是组合关系，公司破产了，部门就不复存在了。部门和员工是聚合关系，部门被裁掉，员工就换下家了。 ❞ 依赖（Dependency） ❝老司机只管开车，车是谁的不重要，给什么车开什么车。 ❞ 什么是组件图？ ❝订单系统组件依赖于客户资源库和库存系统组件。中间的虚线箭头表示依赖关系。另外两个符号，表示组件连接器，一个提供接口，一个需要接口。 ❞ 什么是部署图？ ❝图中简单的表示，不同机器上面部署的不同软件。 ❞ 什么是对象图？ […]
有机会可以看看其证明：https://www.zhihu.com/question/63711252
来源：developer.aliyun.com/article/889271 本文准备围绕七个点来讲网关,分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比,对基础概念熟悉的朋友可以根据目录查看自己感兴趣的部分。 # 什么是网关 网关,很多地方将网关比如成门, 没什么问题, 但是需要区分网关与网桥的区别, 网桥工作在数据链路层，在不同或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可连接两个或多个网络，在其中传送信息包。 网关是一个大概念，不具体特指一类产品，只要连接两个不同的网络都可以叫网关,网桥一般只转发信息,而网关可能进行包装。 # 网关通俗理解 你看看,网关的作用是不是就是这三个, 最终目的就是减少你与集团的耦合,具体到计算机上就是减少客户端与服务端的耦合,如果没有网关意味着所有请求都会直接调用服务器上的资源,这样耦合太强了,服务器出了问题,客户端会直接报错, 例如老板换工作的地方了,如果没有网关你直接去原来的地方找, 肯定会被告知老板不在这儿。 # 为什么需要网关 当使用单体应用程序架构时，客户端（Web 或移动端）通过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。然后应用程序会查询各种数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题,另外内外耦合严重。 客户端可以直接向每个微服务发送请求，其问题主要如下： 客户端需求和每个微服务暴露的细粒度 API 不匹配。 部分服务使用的协议不是Web友好协议。可能使用 Thrift 二进制 RPC，也可能使用 AMQP 消息传递协议。 微服务难以重构。如果合并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就非常困难了。 服务端的各个服务直接暴露给客户端调用势必会引起各种问题。同时，服务端的各个服务可扩展和伸缩性很差。API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上，如前所述的这些功能适合在 API 网关实现。 # 网关与服务器集群 回到我们服务器上,下面图介绍了网关(Gateway)作用,可知 Gateway 方式下的架构，可以细到为每一个服务的实例配置一个自己的 Gateway，也可以粗到为一组服务配置一个，甚至可以粗到为整个架构配置一个接入的 Gateway。于是，整个系统架构的复杂度就会变得简单可控起来。网关可以是多层的。 这张图展示了一个多层 Gateway 架构，其中有一个总的 Gateway 接入所有的流量(流量网关)，并分发给不同的子系统，还有第二级 Gateway 用于做各个子系统的接入 Gateway(业务网关)。可以看到，网关所管理的服务粒度可粗可细。通过网关，我们可以把分布式架构组织成一个星型架构，由网络对服务的请求进行路由和分发。下面来聊聊好的网关应该具备哪些功能,也就是网关设计模式。 # 网关设计思路 […]
转自 原创 方圆(铭楚) 阿里开发者 2022-09-26 09:00 发表于北京 前言 单元测试是软件开发过程中的重要一环，好的单测可以帮助我们更早的发现问题，为系统的稳定运行提供保障。单测还是很好的说明文档，我们往往看单测用例就能够了解到作者对类的设计意图。代码重构时也离不开单测，丰富的单测用例会使我们重构代码时信心满满。虽然单测如此重要，但是一直来都不是很清楚其运行原理，也不知道为什么要做这样或那样的配置，这样终究是不行的，于是准备花时间探究下单测原理，并在此记录。 当在IDEA中Run单元测试时发生了什么？ 首先，来看一下当我们直接通过IDEA运行单例时，IDEA帮忙做了哪些事情： 将工程源码和测试源码进行编译，输出到了target目录 通过java命令运行com.intellij.rt.junit.JUnitStarter，参数中指定了junit的版本以及单测用例名称 这里着重追下JUnitStarter的代码，该类在IDEA提供的junit-rt.jar插件包中，具体目录：/Applications/IntelliJ IDEA.app/Contents/plugins/junit/lib/junit-rt.jar。可以将这个包引入到我们自己的工程项目中，方便阅读源码： JUnitStarter的main函数 这里主要有两个核心方法 接下来看下prepareStreamsAndStart方法运行的时序图，这里以JUnit4为例： 当IDEA确认好要启动的框架版本后，会通过类的全限定名称反射创建IdeaTestRunner的实例。这里以JUnit4为例，IDEA会实例化com.intellij.junit4.JUnit4IdeaTestRunner类对象并调用其startRunnerWithArgs方法，在该方法中会通过buildRequest方法构建org.junit.runner.Request，通过getDescription方法获取org.junit.runner.Description，最后创建org.junit.runner.JUnitCore实例并调用其run方法。 简而言之就是，IDEA最终会借助Junit4框架的能力启动并运行单测用例，所以接下来有必要对Junit4框架的源码做些深入的探究。 Junit4源码探究 Junit是一个由Java语言编写的单元测试框架，已在业界被广泛运用，其作者是大名鼎鼎的Kent Beck和Erich Gamma，前者是《重构：改善既有代码的设计》和《测试驱动开发》的作者，后者则是《设计模式》的作者，Eclipse之父。Junit4发布于2006年，虽然是老古董了，但其中所蕴含的设计理念和思想却并不过时，有必要认真探究一番。 首先我们还是从一个简单的单测用例开始： 这里我们不再通过IDEA的插件启动单元测试，而是直接通过main函数，核心代码如下： 着重看下runner.run(request.getRunner())，先看run函数的代码： 可以看到最终运行哪种类型的测试流程取决于传入的runner实例，即不同的Runner决定了不同的运行流程，通过实现类的名字可以大概猜一猜，JUnit4ClassRunner应该是JUnit4基本的测试流程，MockitoJUnitRunner应该是引入了Mockito的能力，SpringJUnit4ClassRunner应该和Spring有些联系，可能会启动Spring容器。 现在，我们回过头来看看runner.run(request.getRunner())中request.getRunner()的代码： 可以看到Runner是基于传入的测试类（testClass）的信息选择的，这里的规则如下： 如果解析失败了，则返回ErrorReportingRunner 如果测试类上有@Ignore注解，则返回IgnoredClassRunner 如果测试类上有@RunWith注解，则使用@RunWith的值实例化一个Runner返回 如果canUseSuiteMethod=true，则返回SuiteMethod，其继承自JUnit38ClassRunner，是比较早期的JUnit版本了 如果JUnit版本在4之前，则返回JUnit38ClassRunner 如果上面都不满足，则返回BlockJUnit4ClassRunner，其表示的是一个标准的JUnit4测试模型 我们先前举的那个简单的例子返回的就是BlockJUnit4ClassRunner，那么就以BlockJUnit4ClassRunner为例，看下它的run方法是怎么执行的吧。 首先会先走到其父类ParentRunner中的run方法 这里有必要展开说下Statement，官方的解释是：Represents one or more actions to be taken at runtime in the course of running a JUnit […]
前言 Java 19 引入了Virtual Threads并Preview，这个便是协程，对于它的实现原理还未做了解，理论上应该为此在JVM层面会有一些Support，但也有一个疑惑，就是在此之前，不少JVM语言已经有协程了，它们是如何在API层面来实现这个的呢（似乎JVM不支持这个的样子），所以对Kotlin的协程做了些了解，虽然当前还是很懵，但也算有些收获。文章主体引用了文末的第一篇文章。第一篇有些浅显，第二篇比较详细，有时间慢慢看一下。 总结下kotlin的协程实现原理：continuation 方法+ 状态机（每个continuation 风格的方法会创建一个状态机） 为什么使用Kotlin协程 在 Android 上，避免阻塞主线程是非常必要的。主线程是一个处理所有界面更新的线程，也是调用所有点击处理程序和其他界面回调的线程。因此，主线程必须顺畅运行才能确保出色的用户体验 在实际开发中我们会遇到这种场景 创建子线程执行耗时操作，然后切换到主线程处理界面显示逻辑；但是如果我们在一个接口请求完成后，拿到这个接口返回的结果，在需要去请求另一个接口时，逻辑就会十分复杂，就会出现回调地狱；并且如果在需要考虑接口失败的场景呢？ 使用Rxjava优化上面的场景；没有内存泄漏、支持取消、正确的使用线程，但是它比较复杂，如 subscribeOn、observeOn、map 或者 subscribe，都需要学习 这个时候kotlin 协程就出场了，它可以帮我们解决上面的痛点 前置知识 在阅读 Kotlin 源码之前，可以先了解一些前置知识。 Function Function 是 Kotlin 对函数类型的封装，对于函数类型，它会被编译成 FunctionX 系列的类： Kotlin 提供了从 Function0 到 Function22 之间的接口，这意味着我们的 lambda 函数最多可以支持 22 个参数，另外 Function 接口有一个 invoke 操作符重载，因此我们可以直接通过 () 调用 lambda 函数： 编译成 Java 代码后： 可以看到对于 lambda […]
转自 在软件开发领域，「异地多活」是分布式系统架构设计的一座高峰，很多人经常听过它，但很少人理解其中的原理。 异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？ 这些疑问，想必是每个程序看到异地多活这个名词时，都想要搞明白的问题。 有幸，我曾经深度参与过一个中等互联网公司，建设异地多活系统的设计与实施过程。所以今天，我就来和你聊一聊异地多活背后的的实现原理。 认真读完这篇文章，我相信你会对异地多活架构，有更加深刻的理解。 这篇文章干货很多，希望你可以耐心读完。 01 系统可用性 要想理解异地多活，我们需要从架构设计的原则说起。 现如今，我们开发一个软件系统，对其要求越来越高，如果你了解一些「架构设计」的要求，就知道一个好的软件架构应该遵循以下 3 个原则： 高性能 高可用 易扩展 其中，高性能意味着系统拥有更大流量的处理能力，更低的响应延迟。例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。 易扩展表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。 而「高可用」这个概念，看起来很抽象，怎么理解它呢？通常用 2 个指标来衡量： 平均故障间隔 MTBF（Mean Time Between Failure）：表示两次故障的间隔时间，也就是系统「正常运行」的平均时间，这个时间越长，说明系统稳定性越高 故障恢复时间 MTTR（Mean Time To Repair）：表示系统发生故障后「恢复的时间」，这个值越小，故障对用户的影响越小 可用性与这两者的关系： 可用性（Availability）= MTBF / (MTBF + MTTR) * 100% 这个公式得出的结果是一个「比例」，通常我们会用「N 个 9」来描述一个系统的可用性。 从这张图你可以看到，要想达到 4 个 9 以上的可用性，平均每天故障时间必须控制在 […]
当下已来到了2.17.0版本。另外logback-1.2.9之前的版本也有LDAP漏洞 后续再看 针对与Spring Boot项目，一般都是用的日志门面slf4j, 然后springboot-starter-web会依赖logging, 而logging会依赖log4j-to-slf4j, 而它又依赖 log4j-api 但是log4j-api中并没有 Lookup相关的代码，也许不少是不必升级的。详见https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot 根据源码，问题应该指的是 log4j-core 这个包中 的 org.apache.logging.log4j.core.lookup.JndiLookup, 细粒度的可以从这个角度排查 漏洞修复方案： Apache官方已发布补丁，建议受影响的用户尽 快升级到安全版本。补丁下载地址： https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.15.0 https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0 https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.12.2 因为idk 1.8.121以上默认禁止trustURLCodebase去加载远程类，利用ldap及rmi的rce都会失效。所以可以升级下jdk。 漏洞缓解措施：（视版本，有的不适用，具体看扩展部分） （1）修改 jvm 参数 -Dlog4j2.formatMsgNoLookups=true （2）修改配置 log4j2.formatMsgNoLookups=True （3）将系统环境变量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true 扩展 JNDI（Java Naming and Directory Interface,Java命名和目录接口） Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1 Descripton: […]