All posts by 龙生
里氏替换原则
里氏替换原则(Liskov Substitution Principle,LSP)由麻省理工学院计算机科学实验室的里斯科夫(Liskov)女士在 1987 年的“面向对象技术的高峰会议”(OOPSLA)上发表的一篇文章《数据抽象和层次》(Data Abstraction and Hierarchy)中提出:继承必须确保超类拥有的性质在子类中仍然成立(Inheritance should ensure that any property proved about supertype objects also holds for subtype objects)。也就是说:当一个子类的实例能够替换任何父类的实例时,它们之间才具有is-A关系。
View Details解决go: go.mod file not found in current directory or any parent directory; see 'go help modules'
当go build的时候报错如下(或者golang的版本从1.6升级到1.16之后报错如下)
go module是go官方自带的go依赖管理库,在1.13版本正式推荐使用
go module可以将某个项目(文件夹)下的所有依赖整理成一个 go.mod 文件,里面写入了依赖的版本等 使用
go module之后我们可不用将代码放置在src下了 使用 go module 管理依赖后会在项目根目录下生成两个文件 go.mod 和go.sum
Compare the Best Domain Hosting of 2022
Compare the Best Domain Hosting of 2022
Search our expert reviews to compare the leading domain hosting companies. Learn more about their special offers & get your site up and running, today.
https://www.top10.com/hosting/domainhosting-comparison
View DetailsNetty 入门 — 什么是 Netty?
Netty 是 一个异步事件驱动的网络应用程序框架,用于快速开发可维护的高性能协议服务器和客户端。
Netty 是一个 NIO 客户端服务器框架,可以快速轻松地开发协议服务器和客户端等网络应用程序。它极大地简化和流线了网络编程,例如 TCP 和 UDP 套接字服务器。
“快速和简单”并不意味着生成的应用程序会受到可维护性或性能问题的影响。Netty 是经过精心设计的,它借鉴了许多协议(如 FTP、SMTP、HTTP 以及各种基于二进制和基于文本的遗留协议)的实现经验。因此,Netty 成功地找到了一种方法,可以在不妥协的情况下实现易于开发、性能、稳定性和灵活性。
View DetailsJava网络编程IO模型 — BIO、NIO、AIO详解
1.1 I/O模型基本说明
I/O模型的简单理解:I/O模型就是用什么样的通道进行数据的发送和接受,很大程度上决定了程序通信的性能
1.2 Java支持的3种网络编程I/O模式:BIO、NIO、AIO
1.3 JavaBIO(同步阻塞)
1.4 JavaNIO (同步非阻塞)
1.5 JavaAIO(异步非阻塞)
解决出现“未能加载文件或程序集“System.Net.Http.Formatting, Version=5.2.3.0”的问题
我们在使用C#开发WebApi等相关程序时,可能因为某些原因会出现如下图所示的错误,原因就是我们在编译的时候,使用的dll库可能和最初的发生了改变,导致版本不一致造成的。
View DetailsWindows下安装docker后的默认操作系统密码
通过DockerToolbox在win7上构建了docker的环境,启动了ORACLE VM VirtualBOX下的Default 操作系统。
这个操作系统默认的IP是192.168.99.100,可以直接通过ORACLE VM VirtualBOX的控制台“显示”按钮展现shell(以root账号进入的)。
这种访问的缺点:
就是默认的shell展现屏幕不够大,使用不够方便;
解决方案:
通过SSH客户端访问,这里我使用putty访问这个系统;
docker run参数-v的rw、ro详解
众所周知,如果启动容器时不使用-v挂载宿主机的文件或文件夹,容器中的配置文件只能进入容器才能修改,输出的日志文件也是在容器里面,查看不方便,也不利于日志收集,所以一般都是使用-v参数来挂载文件或文件夹。
View Details踩坑备忘录—Nginx反向代理之server_name与ip
我们的系统依赖一个第三方的服务,该服务是通过IP限制访问权限的。出于安全考虑,我们的系统会校验证书,因此我们采用Nginx反向代理去访问该服务。该服务迁移到cloud上之后,我们系统出现了问题。 Nginx的配置文件如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
http { upstream backend.example.com { server backend1.example.com:443; } server { listen 80; server_name www.example.com; location /upstream { proxy_pass https://backend.example.com; proxy_ssl_certificate /etc/nginx/client.pem; proxy_ssl_certificate_key /etc/nginx/client.key; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt; proxy_ssl_verify on; proxy_ssl_verify_depth 2; } } } |
Debug 在出现线上问题的时候,第一时间检查了配置文件的改动记录 ⇒ 配置文件没有改到。 接着检查了,证书是否过期⇒没有过期。 通过域名curl请求 ⇒ 第三方服务正常,证书正确。 在我们没有任何改动的情况下,第三方服务也是单纯地做了迁移,然后就挂了。 思考了很久之后,Nginx没有任何改动,那么出问题的一定不是我们。那么出问题一定是第三方,最直接的方式是联系第三方提供商,联系渠道很繁琐,时间成本也会很高。为了快速修复问题,我们决定盲调Bug。 尝试解决 第一次尝试,已知curl请求一切正常。尝试着将upstream干掉,直接写道proxy_path中。依旧是失败,错误日志中出现了”https://1.1.1.1:443 TLS handshake failed”。推断,proxy_path会将域名转换成ip。 第二次尝试,尝试检查curl ip来访问服务。失败。推断,IP和域名指向了两个不同的服务。到这里算是找到root cause了。 解决思路:反向代理时候,通过域名访问而不是IP访问。 查询文档,发现可以使用配置项:proxy_ssl_server_name,该配置项默认值是off,需要将一些内容写到配置文件中:
1 |
proxy_ssl_server_name on; |
第三次尝试,将proxy_ssl_server_name on写入到配置文件中。成功。 什么是server_name 服务器名称指示(Server Name Indication, SNI)是对TLS协议的扩展。在握手过程开始时,通过该协议,客户端指示其尝试连接的主机名。该协议允许服务器上的同一个IP和TCP端口拥有多个证书,因此允许同一个IP地址为多个HTTPS网站提供服务,且无需所有网站使用相同的证书。 from:https://www.realks.com/2021/03/07/nginx-proxy-ssl-server-name/
View Details