‘Java Builder’ https://juejin.im/entry/5b83fe1851882542e16bfcf6 Java 中的 Builder 模式和协变返回类型 阅读 735 收藏 45 2018-08-27 原文链接: www.codebelief.com 阅读这篇文章大约需要五到十分钟时间。 Builder 模式是一种创建型的设计模式，即解决对象的创建问题。 在 Java、C++ 这类语言中，如果一个类在创建时存在可选参数，那么可以通过函数重载来实现，但是如果可选参数非常多的话，构造函数的数量也会变得非常多，并且可能因为不同可选参数类型相同而没法重载，我们接下来通过例子来说明。 一、可选参数带来的问题 不可重载的情况 //学号、姓名是必须参数，身高、体重可选 public Student(int id, String name) {} public Student(int id, String name, float height, float weight) {} public Student(int id, String name, float height) {} //只填身高 public Student(int id, String name, float weight) {} //只填体重 (签名重复，无法重载) 虽然最后两个构造方法参数名不同，但是它们类型相同，方法签名也就相同，因此没办法重载，只能保留一个。 构造方法数量过多 接着考虑这么一个场景，你正在设计一个 Person 类，这个类存放了 name、age、sex 等信息，其中 name 是必要信息，而 age 和 sex 是可选信息，那么你可能会编写如下的构造方法: ...

Kafka, offset offset的保存 一个消费组消费partition，需要保存offset记录消费到哪，以前保存在zk中，由于zk的写性能不好，以前的解决方法都是consumer每隔一分钟上报一次。这里zk的性能严重影响了消费的速度，而且很容易出现重复消费。 在0.10版本后，kafka把这个offset的保存，从zk总剥离，保存在一个名叫__consumeroffsets topic的topic中。写进消息的key由groupid、topic、partition组成，value是偏移量offset。topic配置的清理策略是compact。总是保留最新的key，其余删掉。一般情况下，每个key的offset都是缓存在内存中，查询的时候不用遍历partition，如果没有缓存，第一次就会遍历partition建立缓存，然后查询返回。 作者: 123archu 链接: https://www.jianshu.com/p/d3e963ff8b70 来源: 简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。 https://blog.csdn.net/u012129558/article/details/80075270 对Kafka offset的管理，一直没有进行系统的总结，这篇文章对它进行分析。 什么是offset offset是consumer position，Topic的每个Partition都有各自的offset. Keeping track of what has been consumed, is, surprisingly, one of the key performance points of a messaging system. Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structure used for storage in many messaging systems scale poorly, this is also a pragmatic choice-since the broker knows what is consumed it can immediately delete it, keeping the data size small. ...

goexec `bash goexec ‘strings.Repeat(“Go! “, 5)’ goexec ‘http.ListenAndServe(":8080”, http.FileServer(http.Dir(”.")))'` https://github.com/shurcooL/goexec#goexec

golang WebAssembly https://github.com/golang/go/wiki/WebAssembly https://tutorialedge.net/golang/go-webassembly-tutorial/ package main import "fmt" func main() { fmt.Println("Hello, WebAssembly!") } gOOS=js GOARCH=wasm go build -o main.wasm cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" . go get -u github.com/shurcooL/goexec goexec 'http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))'

golang kafka https://github.com/Shopify/sarama https://github.com/bsm/sarama-cluster

Kafka 文件存储机制 Kafka 是什么 Kafka 是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 1.前言 一个商业化消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。 下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 2.Kafka文件存储机制 Kafka部分名词解释如下: Broker: 消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。 Topic: 一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。 Partition: topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。 Segment: partition物理上由多个segment组成，下面2.2和2.3有详细说明。 offset: 每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息. 分析过程分为以下4个步骤: topic中partition存储分布 partiton中文件存储方式 partiton中segment文件存储结构 在partition中如何通过offset查找message 通过上述4过程详细分析，我们就可以清楚认识到kafka文件存储机制的奥秘。 2.1 topic中partition存储分布 假设实验环境中Kafka集群只有一个broker，xxx/message-folder为数据文件存储根目录，在Kafka broker中server.properties文件配置(参数log.dirs=xxx/message-folder)，例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4 存储路径和目录规则为: 复制代码 xxx/message-folder |--report_push-0 |--report_push-1 |--report_push-2 |--report_push-3 |--launch_info-0 |--launch_info-1 |--launch_info-2 |--launch_info-3 复制代码 在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。 如果是多broker分布情况，请参考kafka集群partition分布原理分析 2.2 partiton中文件存储方式 下面示意图形象说明了partition中文件存储方式: image 图1 每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。 这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。 2.3 partiton中segment文件存储结构 读者从2.2节了解到Kafka文件系统partition存储方式，本节深入分析partion中segment file组成和物理结构。 segment file组成: 由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和".log"分别表示为segment索引文件、数据文件. ...

响应式编程, Reactive Programming, 反应式编程 Reactive Programming 作为观察者模式 (Observer） 的延伸，不同于传统的命令编程方式 ( Imperative programming） 同步拉取数据的方式，如迭代器模式 (Iterator）。而是采用数据发布者同步或异步地推送到数据流 (Data Streams）的方案。当该数据流 (Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bug 出现的目的。同时，Reactive Programming 结合背压 (Backpressure） 的技术解决发布端生成数据的速率高于订阅端消费的问题。 https://developer.aliyun.com/article/617709 响应式编程为 Java 的企业版应用提供了更高的性能，并降低了内存消耗，主要是通过减少进程的上下文切换来实现的。因为类似的上下文切换对 CPU 和内存的消耗是极大，所以要尽可能的减少这样的切换操作。不过，响应式编程带来的这种性能上的提高，代价是降低了软件的维护性 java 使用一对一的线程模型,一个java线程对应一个内核线程, 高并发情况下 线程上下文切换成为了瓶颈. 而这正是响应式编程的用武之地，它与目前的 Java 线程模型完全相反。目前的线程模型是保证所有的事情都在当前线程执行，但是在响应式编程中，异步是一个准则。一个程序执行过程被认定为一系列异步执行的事件，每个事件都被 Publisher 创建，你不需要关心 Publisher 在哪个线程中创建。在响应式程序里面，程序代码包含了监听和执行异步事件的功能，而且会在必要时提供新的事件。 这个方式在某些场景下很有效果，比如说在程序里面访问外部数据库。传统的企业级 Java 程序里面，系统会发送一段 SQL 语句到数据库上面，阻塞住程序，直到数据库返回查询结果。但是在响应式编程里面，程序会跳过等待结果的过程，正常向下执行代码。当你发送一个 SQL 请求到数据库的时候，会用一个 Pushlisher 来替代阻塞的过程，调用者可以注册这个 Pushlisher，这样的话，在之后数据库返回结果的时候，就会通知 Publisher，然后 Publisher 会通知调用者。 响应式编程的好处就是执行的代码和执行的线程是分开的。因此在操作系统的层面上，上下文切换的代价比较低。 响应式编程也有一些比较严重的问题，写入的代码和执行的代码分离开来，导致阅读和编写代码的难度增加，对于这种异步的代码，编写单元测试和调试代码都很困难。 类似于 C Sharp、JavaScript、Kotlin 等这一类的编程语言在这个领域已经走在了前面，他们在编程语言中集成了这部分功能，可以帮助你执行一小段异步代码，并在返回的时候阻塞，直到执行结束。在 C Sharp 和 JavaScript 中，可以使用 Async 和 Await 关键字，在 Go 和 Kotlin 中，同样包括了协程的概念来提供类似的功能。 ...

maven-shade-plugin maven build fat jar

‘命令行, curl 查询公网 ip’ curl ifconfig.me curl whatismyip.akamai.com curl https://ip.cn curl icanhazip.com curl ident.me curl tnx.nl/ip curl myip.dnsomatic.com https://blog.csdn.net/liu0808/article/details/80769810 curl http://members.3322.org/dyndns/getip # 保存到文件 wget http://ifconfig.me/ip wget http://members.3322.org/dyndns/getip http://blog.csdn.net/teddy17/article/details/12618035 curl http://myip.ipip.net/ curl cip.cc curl ifconfig.me curl myip.ipip.net curl http://members.3322.org/dyndns/getip

shell basic, shell script sample #!/usr/bin/env bash echo 'hello world' commands # to refresh your current bash session exec bash Shell 函数, function # 参数不在函数名后面的括号里定义 [ function ] funname [()] { action; [return int;] } # 定义函数 fun0 fun0(){ echo "run fun0: " + $1 } # 调用函数 fun0 fun0 "foo" # 定义带参数的函数 fun0 # 在Shell中，调用函数时可以向其传递参数。在函数体内部，通过 $n 的形式来获取参数的值，例如，$1表示第一个参数，$2表示第二个参数... fun0(){ echo "run fun0 $1 " echo "第一个参数为 $1 !" echo "第二个参数为 $2 !" echo "第十个参数为 $10 !" } # 调用带参数的函数 fun0 fun0 foo # check if params is not supplied if [ $# -eq 0 ] then echo "No arguments supplied" fi https://www.runoob.com/linux/linux-shell-func.html ...

用户故事, user story 故事story是粗略的勾勒的需求，它是信！号！卡！，指向真正的需求或者叫故事详情，怎么说都好。 而需求就是需求。 这里隐含了敏捷的一个要素，就是，延！迟！决！策！ 当需求不是被细化的摆放着，而是粗略的STORY的时候，才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前，我们才去细化STORY故事，把他变成需求。或者，开发前，我们扔掉STORY，因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的，而且保证我们不会遗漏。所以这里，就是为什么敏捷要用STORY而不是需求去进行需求的管理。 作者: 马菲菲 链接: https://www.zhihu.com/question/26996772/answer/35078718 来源: 知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 用户故事 https://www.tapd.cn/forum/view/43571 https://www.cnblogs.com/jetlian/p/3946359.html http://www.scrumcn.com/agile/scrum/4823.html http://www.scrumcn.com/agile/scrum/20026.html https://blog.csdn.net/GitChat/article/details/78410016 用户故事 (User Story) 和验收标准 (Acceptance Criteria) 那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求 (requirement) ，被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。最常见使用的标准格式的用户故事如下: 作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。 什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。格式如下: 在我做某些动作 (action) 之前请赐给一些先决条件，然后期望结果发生。举个栗子: 1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如"摄像头无法打开"…，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了"完成标准的定义"。作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。 https://www.jianshu.com/p/bde45187a78f

Theme, epic,feature,user story 在敏捷项目的估算或计划时，我们常提到以下几个概念。talent.mypm.net · Epic Storyservice.mypm.net · Feature项目经理圈子 · Minimal Marketable Feature (MMF)项目管理者联盟 · Theme项目管理者联盟 · User Story项目管理培训 · Tasktalent.mypm.net 本文将说明这几个概念的意义和他们间的关系。项目管理者联盟 FeaturePgMp.mypm.net Feature是可以为顾客提供价值的东西，它代表一个产品可以做什么，或提供什么服务;是可以满足用户的需求，为客户服务，为用户带来真正的价值的成果物的特性。PgMp.mypm.net Feature相对复杂，可由一组动宾结构的句子表达，如一个超市的交易可以描述为: blog.mypm.net · 扫描条形码项目管理者联盟 · 显示单价PgMp.mypm.net · 计算总价项目管理者联盟 · 计算税额项目管理者联盟 · 打印清单项目管理者联盟文章 因此，一个Feature是很难进行估算的，它需要被分解成一个个更小的单位，这就是下面要讨论的User Story。Feature一般在Release Plan的层次，一个Feature可能需要几次迭代才能完成。项目管理者联盟 由于Feature是满足用户需求的交付物，因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的"Working software"。转自项目管理者联盟 Minimal Marketable Feature (MMF)项目管理者联盟 了解了什么时Feature后，我们再来讨论MMF。顾名思义，MMF就是一组最小的，可以市场化的机能。首先，它是Feature，其次，它强调的是市场化这个概念。市场化意味着它能够提交到用户手中使用，并可以从用户那里得到相应的回报。MMF可以使得投资提前取得收益，这对于一个企业来说，是非常重要和实用的。blog.mypm.net User Story项目管理者联盟 在Feature的讨论中提到了，Feature是由一组动宾结构的句子组成的。这些动宾句子描述的就是一个个User Story。一个Feature可以分解成多个User Story，每个User Story不能单独被使用，而是一起构成一个Feature。PgMp.mypm.net 一个User Story必须是清晰的，可以为客户增加价值，而且更重要的是能够被估算。因此User Story通常是进行估算的基本单位，通常使用Story Point来进行估算。User Story是在迭代的层级，一个User Story要在一个迭代内完成。项目管理者联盟文章 另外，User Story也是进行需求分析的工具。通过询问谁、做什么、为什么，能够简单明了地扑捉客户的需求。因此User Story通常写成以下形式: 项目经理圈子 As a , I want , so than .项目管理者联盟 ...

hyper -v 端口映射 https://www.cnblogs.com/cnxkey/articles/7815434.html hyper -v 如何实现端口映射 如果你是想由虚拟机来提供相应的服务，比如虚拟机里安装web服务，将物理主机的web端口映射到虚拟机，可以使用如下命令进行设置即可，我已经成功了。 一、查询端口映射情况 netsh interface portproxy show v4tov4 查询这个IP所有的端口映射。 netsh interface portproxy show v4tov4|find “192.168.1.1” 二、增加一个端口映射 netsh interface portproxy add v4tov4 listenport=外网端口 listenaddress=主IP connectaddress=私网IP connectport=私网IP端口 例如: netsh interface portproxy add v4tov4 listenport=8888 listenaddress=118.123.13.180 connectaddress=192.168.1.10 connectport=2222 三、删除一个端口映射 netsh interface portproxy delete v4tov4 listenaddress=主IP listenport=外网端口 例如: netsh interface portproxy delete v4tov4 listenaddress=118.123.13.180 listenport=8888 在关闭Hyper-V虚拟机的情况下，选择Hyper-V管理界面中的"虚拟交换机管理器" 在弹出的对话框中"新建虚拟网络交换机"，选择"内部"，点击"创建虚拟交换机"。 在IP网卡 切换到"共享"标签下，勾选"允许其他网络用户通过此计算机的Internet连接来连接"并在下方"家庭网络连接"中选择刚刚创建的虚拟交换机——vEthernet (Hyper-V Switch)，点击"确认

Product Backlog Product Backlog由所有的功能特性，包括业务功能，非业务功能 (技术、架构和工程实践相关) ，提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。 一个完整的Backlog是一个蓝图，可以根据它来把产品改造成为我们期望的样子。 但是在Scrum中，Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的，我们会持续的改变它去确保我们的产品是最合理的，最有竞争力的，最有价值的。 当我们去看产品的Backlog的时候，优先级是一个重要的视角，优先级越高的Backlog需要越清晰，越详细。对于优先级低的Backlog，详细程度会越低，直到几乎我们不能认为它是一个Backlog项 (非常低的优先级，只相当于一个占位符，来用做提醒) 。 评算(Esitimate) 对每个backlog项做估算 (包括成本，复杂度，风险，功能点) 。优先级越高的Backlog估算要越精确，在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化 (对于那些很重要，并且可以快速解决的问题可以先做) 。 我们要经常做估算。 创建者(Creater) Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点，销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活，更具扩展性，可复用性，开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。 重要程度(Importance) 每个Backlog项都有优先级，这些backlog项按照优先次序排行队列放在Backlog列表中。在评估的过程中 我需要在"什么样的产品特性，技术架构，缺陷的修复才会给产品公司和它的客户带来带来最大的收益？ " 和"什么样的技术架构，工程方法使我们可以更快，更高质量的交付版本"之间做出抉择。不论是对内部技术环境或者外部市场，我们都需要不断筛选和评估什么是最重要的。 版本发布(Release) 规划接下来的几个版本，包括版本的目标，及可能包含的内容。 (我们可能需要在发布内容，开发成本及发布周期之间做出抉择) 。 产品Backlog要按照Release分组，要让开发团队的所有成员都全部的了解总体开发目标，并且确保所有的技术问题都做了充分的考虑并且放入了产品Backlog. 负责人(Product Owner) 我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表，对于商业产品的开发， Backlog的负责人也许会是产品经理，对于内部项目的开发Backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品Backlog的优先级和工作量估算，同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。 优先级(Priority) 只有一个人来进行排序的工作，这个人的职责是确保达成产品的愿景，提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级，他们必须说服这个负责人去改变。 可视化(Visualization) 产品的Backlog需要能够让开发团队，利益相关者等相关的人能够很容易的看到它的内容，状态，进展等等。 以下是引用《硝烟中的Scrum和XP-我们如何实施Scrum (Henrik Kniberg著) 》 中讲述他们如何编写Product Backlog: Product Backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事 (Story) ，有时候也叫做Backlog条目。 我们的故事包括这样一些字段: ID——统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。 Name (名称) ——简短的、描述性的故事名。比如"查看你自己的交易明细"。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。 Importance (重要性) ——产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。 o 我一直都想避免"优先级"这个说法，因为一般说来优先级1都表示"最高"优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？ Initial Estimate (初始估算) ——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点 (story point) ，一般大致相当于一个"理想的人天 (man-day) “。 o 问一下你的团队，“如果可以投入最适合的人员来完成这个故事 (人数要适中，通常为2个) ，把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证，可以交付的完整实现呢？“如果答案是"把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。 o 不需要保证这个估值绝对无误 (比如两个故事点的故事就应该花两天时间) ，而是要保证相对的正确性 (即，两个点的故事所花费的时间应该是四个点的故事所需的一半) ...

Bcrypt https://www.jianshu.com/p/2b131bfc2f10 Bcrypt 是单向 Hash 加密算法，类似 Pbkdf2 算法 不可反向破解生成明文。 每次输出的 hashPass 都不一样， Bcrypt 是怎么加密的？ Bcrypt 有四个变量: saltRounds: 正数，代表hash杂凑次数，数值越高越安全，默认10次。 myPassword: 明文密码字符串。 salt: 盐，一个128bits随机字符串，22字符 myHash: 经过明文密码password和盐salt进行hash，个人的理解是默认10次下 ，循环加盐hash10次，得到myHash 每次明文字符串myPassword过来，就通过10次循环加盐salt加密后得到myHash, 然后拼接BCrypt版本号+salt盐+myHash等到最终的bcrypt密码 ，存入数据库中。 这样同一个密码，每次登录都可以根据自省业务需要生成不同的myHash, myHash中包含了版本和salt，存入数据库。 作者: martin6699 链接: https://www.jianshu.com/p/2b131bfc2f10 来源: 简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。 https://www.ujcms.com/knowledge/509.html http://www.mindrot.org/projects/jBCrypt/ https://www.cnblogs.com/jpfss/p/11024716.html http://www.mindrot.org/projects/jBCrypt/ 在 Java 中使用 Bcrypt, BCryptPasswordEncoder 如果引入了 Spring Security, BCryptPasswordEncoder 提供了相关的方法。 public class BCryptPasswordEncoderTest { public static void main(String[] args) { String pass = "admin"; BCryptPasswordEncoder bcryptPasswordEncoder = new BCryptPasswordEncoder(); String hashPass = bcryptPasswordEncoder.encode(pass); System.out.println(hashPass); boolean f = bcryptPasswordEncoder.matches("admin",hashPass); System.out.println(f); } } 可以看到，每次输出的 hashPass 都不一样， 但是最终的f都为 true,即匹配成功。 ...

openvpn docker export OVPN_DATA="ovpn-data" docker volume create --name $OVPN_DATA docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_genconfig -u udp://home.wiloon.com docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn ovpn_initpki docker run -v $OVPN_DATA:/etc/openvpn -d -p 192.168.50.220:1194:1194/udp --cap-add=NET_ADMIN --name openvpn --restart=always kylemanna/openvpn docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn easyrsa build-client-full client0 nopass docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_getclient client0 > client0.ovpn # Retrieve the client configuration with embedded certificates docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/rpi-openvpn ovpn_getclient client0 > client0.ovpn docker run -v $OVPN_DATA:/etc/openvpn -p 1194:1194/udp --privileged -e DEBUG=1 kylemanna/rpi-openvpn server 192.168.255.0 255.255.255.0 verb 3 key /etc/openvpn/pki/private/xxxx.key ca /etc/openvpn/pki/ca.crt cert /etc/openvpn/pki/issued/xxx.crt dh /etc/openvpn/pki/dh.pem tls-auth /etc/openvpn/pki/ta.key key-direction 0 keepalive 10 60 persist-key persist-tun proto udp # Rely on Docker to do port mapping, internally always 1194 port 1194 dev tun0 status /tmp/openvpn-status.log user nobody group nogroup comp-lzo no ### Route Configurations Below route 192.168.254.0 255.255.255.0 ### Push Configurations Below push "block-outside-dns" push "dhcp-option DNS 192.168.50.1" push "comp-lzo no" push "redirect-gateway def1 bypass-dhcp"

database DDL > puml https://github.com/wangyuheng/ddl2plantuml java -jar ~/apps/ddl2plantuml.jar foo.sql er.puml docker run \ -e DDL='/mnt/data/ddl.sql' \ -e PLANTUML='/mnt/data/er_by_docker.puml' \ -v ddl2plantuml-data:'/mnt/data' \ wangyuheng/ddl2plantuml:latest

nginx location, root location 语法 Location 块通过指定模式来与客户端请求的URI相匹配。 Location 基本语法： 匹配 URI 类型，有四种参数可选，当然也可以不带参数。 命名 location，用@来标识，类似于定义goto语句块。 location [ = | ~ | * | ^ ] /URI { … } location @/name/ { … } location 匹配命令解释 空 location 后没有参数直接跟标准 URI， 表示前缀匹配，代表跟请求中的 URI 从头开始匹配。 = 用于标准 URI 前，要求请求字符串与其精准匹配，成功则立即处理，nginx 停止搜索其他匹配。 ^~ 用于标准 URI 前，并要求一旦匹配到就会立即处理，不再去匹配其他的正则 URI，一般用来匹配目录 ~ 用于正则 URI 前，表示 URI 包含正则表达式，区分大小写 ~* 用于正则 URI 前， 表示 URI 包含正则表达式，不区分大小写 @ @ 定义一个命名的 location，@ 定义的locaiton名字一般用在内部定向，例如error_page, try_files命令中。它的功能类似于编程中的goto。 location 匹配顺序 nginx 有两层指令来匹配请求 URI。第一个层次是 server 指令，它通过域名、ip 和端口来做第一层级匹配，当找到匹配的 server 后就进入此 server 的 location 匹配。 ...

golang 开发目录结构 https://github.com/golang-standards/project-layout 在实际的项目中发现大家的目录结构都比较凌乱，基本每个人都有每个人的风格，一个项目在不断地变大，一些新的文件或目录又不断地被添加进来，从这里面去找到自己需要的信息的成本越来越高，一个统一的通用的目录结构非常有必要。 以下内容来自于github上的这个项目 (https://github.com/golang-sta…) /cmd main函数文件 (比如 /cmd/myapp.go) 目录，这个目录下面，每个文件在编译之后都会生成一个可执行的文件。 不要把很多的代码放到这个目录下面，这里面的代码尽可能简单。 /internal 应用程序的封装的代码，某个应用私有的代码放到 /internal/myapp/ 目录下，多个应用通用的公共的代码，放到 /internal/common 之类的目录。 /pkg 一些通用的可以被其他项目所使用的代码，放到这个目录下面 /vendor 项目依赖的其他第三方库，使用 glide 工具来管理依赖 /api 协议文件，Swagger/thrift/protobuf 等 /web web服务所需要的静态文件 /configs 配置文件 /init 服务启停脚本 /scripts 其他一些脚本，编译、安装、测试、分析等等 /build 持续集成目录 云 (AMI), 容器 (Docker), 操作系统 (deb, rpm, pkg)等的包配置和脚本放到 /build/package/ 目录 /deployments 部署相关的配置文件和模板 /test 其他测试目录，功能测试，性能测试等 /docs 设计文档 /tools 常用的工具和脚本，可以引用 /internal 或者 /pkg 里面的库 /examples 应用程序或者公共库使用的一些例子 /assets 其他一些依赖的静态资源 https://www.jianshu.com/p/1c47d99f33ed

舱壁模式 什么是舱壁模式 舱壁模式 (Bulkhead) 隔离了每个工作负载或服务的关键资源，如连接池、内存和CPU。 使用舱壁避免了单个工作负载 (或服务) 消耗掉所有资源，从而导致其他服务出现故障的场景。 这种模式主要是通过防止由一个服务引起的级联故障来增加系统的弹性。 工业中使用舱壁将船舶划分为几个部分，以便在船体破坏的情况下，可以将船舶各个部件密封起来。舱壁的概念在软件开发中可以被应用在隔离资源上。通过应用舱壁模式，我们可以保护有限的资源不被耗尽。例如，对于一个有连接数限制的数据库实例来说，如果我们有两种连接它的操作，我们采用可以采用两个连接池的方式进行连接，来代替仅采用一个共享连接池的方式。由于这种客户端与资源进行了隔离，超时或过度使用池的操作页不会使其他操作失败。泰坦尼克号沉没的主要原因之一是其舱壁设计失败，水可以通过上面的甲板倒在舱壁的顶部，导致整个船体淹没。 作者: AskHarries 链接: https://juejin.im/post/5b32d3e36fb9a00e952ce899 来源: 掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。