以下内容格局比较小，仅做个人记录
从我个人接触过的ToB和ToC业务讲，有以下特点（当然肯定不是一定对的，毕竟业务形态实在太多，我没真正接触过的，就不提了）：
关于ToB业务的规范
怎么看待职场中的“业务壁垒”？
在我的工作中，曾经发生过这样一件事：有一天我们在讨论，能不能实现一个业务通用组件，让各个业务接入，提升业务需求的开发效率等，这时候有一个同事就跟我说：‘那如果真的实现的话，那你这边的业务就啥都没了’，言外之意就是我这边“没事做了”。我给他的回答是：‘没关系，只要是有意义，有价值，对公司是正确的就行’
那么？我真的那么爱公司吗？
在工作中，你们到遇到很多“业务壁垒”。通俗来讲，这个东西只有他会，或者短期内只有他能搞定。你甚至会觉得一股恶心，就是很乱很难受，并惊叹对方的忍耐力。
然而，无数的事实证明了，这个世界不会因为没有谁就不行。
而我的原则是：做正确的事，不制造业务壁垒；保持出色的整理学习能力，输出业务文档，让自己随时可替换，甚至寻找可以替换自己的人；不做狭义对自己有利的事，尽量做广义对公司有利的事。
具体来说，可以这样阐述
关于“可替代性”另外补充：
以前刚毕业的时候，进入一个组，叫中间层，那时候还懵懵懂懂不知道想表达啥意思
图来源网上，已未知出处
这个组是直接给app提供接口的，主要的职能大概有以下
聚合服务，简单的来说就是聚合底层的各个业务系统，给用户端应用提供接口
那么这个组有存在的必要吗？特别是现在服务内部都微服务化，很多业务服务都是直接对app提供接口的。
先从表面上看看使不使用聚合层各自的特点和好处
仔细想想，简单理解，其实使用聚合层就是水平架构，不使用就是垂直架构；根据康威定律，其实公司决定使用哪种方案，一定程度还受公司组织关系的影响。
提外话：由于前后端分离的流行。聚合层服务有时候会由前端团队来维护。使用node服务用于聚合页面和后端接口，从而提升性能。相对于传统的聚合层，前端的聚合层比较轻量化，基本是无状态服务，不存储数据和加工数据，纯粹做聚合接口和页面。
职场中有一种奇怪又平常的现象：没出事就没人重视，出事了就各种马后炮。
以软件开发人员平常应对的事情为例，这里其实有一种无奈的解释：
普通的干实事的程序员，最讨厌跟行外人谈收益。就像把代码写好了，自然后续维护成本就低了。但是硬要把他转化为节约多少人力。只想一心老老实实写代码的程序员，好心做个事情还要花费心力想办法给你解释，久而久之自然是多一事不如少一事。所谓劣币驱逐良币，有追求的程序员自然离开了，剩下的可想而知。
那么，难道这个问题就无解吗？
最后讲一个故事
魏文王问扁鹊曰：“子昆弟三人其孰最善为医？” 扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。” 魏文王曰：“可得闻邪？” 扁鹊曰：“长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，镵血脉，投毒药，副肌肤，故名出闻于诸侯。” 魏文王曰：“善。”
善战者无赫赫之功
防患于未然的人不如亡羊补牢者获得的赞誉多
转眼工作十年了，从20年10月开始，断断续续做了近三年的小团队管理，这里作简要总结一下。
所谓小团队管理，其实就是现在说的虚线组长，需要写代码、给团队提供指导等，但是由于不是高级别大领导，不需要应付很多烦人的破事。从这层来看，挺适合我这种性格的人。
以下是以小团队为背景来总结的，格局显得较小；当然每个人的观点不一样，不一定是正确的理解。
可以使用类似Java的MappedByteBuffer来保存数据
缺点：只能保存连续的一定范围的数字对应的值
使用示例：
1 | import org.junit.Test; |
sudo lsof | grep sock | awk '{++S[$1]} END {for(a in S) print a, S[a]}' | sort -nr
sudo lsof | awk '/sock/ {++S[substr($0, index($0, $9))]} END {for(a in S) print a, S[a]}'
sudo lsof | grep sock|grep 'identify protocol'|awk ' {++S[$2]} END {for(a in S) print a, S[a]}'| sort -nr
//打开句柄数目最多的进程
lsof -n|awk '{print $2}'| sort | uniq -c | sort -nr | head
//查看close_wait连接统计：
sudo netstat -anp|grep 'CLOSE_WAIT'|grep 'ssogo'| awk '{print $5}'|sort |uniq -c | sort -nr
//查看FIN_WAIT2连接统计：
sudo netstat -anp|grep 'FIN_WAIT2'|grep 'ssogo'| awk '{print $5}'|sort |uniq -c | sort -nr
//查看CLOSE_WAIT最多的进程
sudo netstat -anp|grep 'CLOSE_WAIT'| awk '{print $7}'|sort |uniq -c | sort -nr
sudo netstat -anp|grep 'FIN_WAIT2'| awk '{print $7}'|sort |uniq -c | sort -nr
具体地，TCP 的 “closed” 状态表示连接已经关闭，不再使用，并且不再具有任何网络连接或状态信息。这些连接处于已经结束的状态，但它们的套接字资源还未被完全释放或回收。
在输出结果中，”closed” 数量是指当前处于已关闭状态的 TCP 连接的数量。这些连接可能是先前已经建立的连接，已经完成了其通信任务，双方都关闭了连接，并且连接的套接字资源等待系统进行资源回收。
需要注意的是，已关闭的连接数量的增加和减少是动态的，因为在系统的运行过程中，套接字的打开和关闭是常见的网络操作。
lsof| grep "can't identify protocol"
如果存在很多，则代表socket泄漏，同时会显示哪个进程使用的sock未关闭。
紧急重启服务（业务Go服务）后socket数量下降
在现场已经没了的情况下，分析发现机器上本身已经存在大量socket泄漏的情况
nginx和gateway都reload，那么nginx会产生新的worker进程，但是应该shutdown的老进程因为和gateway还有连接，所以也不会销毁，这样时间长了会有很多处于shutting状态的进程，这些进程都会占用资源。
初步怀疑是这些异常的nginx worker进程导致的，于是处理所有机器上这些异常（kill）
上图的正常状态下，close_wait和fin_wait2状态的数量，并没那么多
todo： 后续统计一下：
//查看close_wait连接统计：
sudo netstat -anp|grep 'CLOSE_WAIT'|grep 'ssogo'| awk '{print $5}'|sort |uniq -c | sort -nr
//查看FIN_WAIT2连接统计：
sudo netstat -anp|grep 'FIN_WAIT2'|grep 'ssogo'| awk '{print $5}'|sort |uniq -c | sort -nr
//查看CLOSE_WAIT最多的进程
sudo netstat -anp|grep 'CLOSE_WAIT'| awk '{print $7}'|sort |uniq -c | sort -nr
sudo netstat -anp|grep 'FIN_WAIT2'| awk '{print $7}'|sort |uniq -c | sort -nr
通过pprof输出进程的goroutine情况，从数量和堆栈分析，大量goroutine锁住，导致请求被hang住
至此，问题的基本表现分析如下
1 | import socket |
（1） goroutine1: s.mu.RLock()
（2） goroutine2: s.mu.Lock() - 等待（1）
（3） goroutine1: s.mu.RLock() - 等待（2）
相当于goroutine1自己等待自己
在Resolve方法中，对于sql.DB类型的连接，当读取errData映射的错误计数时，使用了RWMutex的读锁（s.mu.RLock()）。但是，在循环的每次迭代中都会调用defer s.mu.RUnlock()，这会在for循环结束时解锁，而不是在每次迭代结束时解锁。
这意味着如果在某次循环迭代中获取了读锁，但在获取下一个读锁之前已经进入了循环的下一次迭代，那么这两次迭代将持有读锁，但没有释放，从而导致死锁。
要解决这个问题，可以将读锁的获取和解锁放在同一次循环迭代中，确保每次获取读锁后都会及时释放，而不会在后续迭代中持有读锁。以下是修改后的代码：
1 | func (s *GuardPolicy) Resolve(connPools []gorm.ConnPool) gorm.ConnPool { |
本质是开一个线程,无限循环,检查本地的当前时间,是否符合执行的条件
Redis: 比如redis-5.0.8，起了一个线程不停的循环检查，比对当前时间（gettimeofday）判断是否需要执行
Golang: 起一个goroutine无限循环,从最小堆中取符合时间的任务
Java: 单线程, 无限循环,最小堆: java.util.TimerThread#mainLoop
定时任务一般分为 本地定时任务 和 分布式定时任务
比如定时加载数据到本地缓存的时候，这时一般就使用本地定时任务
而有些任务定时只需要执行一次， 现在很多服务都不是单点了，这就需要分布式定时任务来进行调度了
业界上可选择的定时任务工具很多，在工作中使用最多的是Saturn，个人觉得还是很方便的，其他分布式定时任务的原理其实基本大同小异
这里Go应用为例子，通过域信号结合shell命令，从而方便使用saturn定时任务
client端：提供shell命令，供saturn定时调用
1 | const SockPath = "/tmp/notify-os.sock" |
1 |
|
使用Java作为编程语言
使用Spring-MVC框架
使用Tomcat作为Web容器
打包运行方式：
使用Java作为编程语言
使用二次开发的Play1.x作为web框架（底层基于Netty）
公司在框架自行研发了服务发现等功能
打包运行方式：
使用Java作为编程语言
使用Spring-Boot框架
使用Tomcat作为Web容器
打包运行方式：
使用Java作为编程语言
使用二次开发的Spring-Boot和Spring-Cloud作为web框架
公司在框架自行研发了服务发现，服务治理，数据库切换、容灾相关等功能
打包运行方式：
使用Lua作为编程语言
使用OpenResty作为服务器
公司开发了一些通用的sdk，在OpenResty配置中include即可
打包运行方式：
nginx -s reload 更新OpenResty的lua文件即可
使用PHP作为编程语言
使用OpenResty作为服务器
打包运行方式：
nginx -s reload 更新OpenResty的PHP文件即可
使用Go作为编程语言
打包运行方式：