Learn and share.
我们伟大的云提供商告诉我们，他们廊坊机房要关停了，要求我们迁移到其他机房，春节前一定要迁移完毕。
和运维、架构沟通后，做了迁移计划，做了演练，虽然时间仓促，问题特别多，但还是扛过去了。
迁移后，不少用户受到了影响，比如有一个省由于网络供应商问题，整个省的用户无法解析DNS。
这其中，印象最深的是，我们一个用户，服务、配置、权限各种都是正确的。但就是无法登录。
分析了几个小时，最后发现，原来是用户机器时间不对，时差有几个小时，在HTTPS请求到达防火墙时，就被干掉了。
设好时间，一切正常。
其实，之前也遇到过两三次类似问题，频率太低了，一开始根本就没考虑这种可能。
2021年黑客攻击事件核心趋势
1、史诗级漏洞震动全网：Log4j、PrintNightmare等“史诗级”漏洞爆发，利用难度低、影响范围广，从IT系统蔓延至工业控制，修复难度极大。
2、0day漏洞“军备竞赛”：微软Exchange漏洞被国家级APT组织（如Hafnium）大规模利用，数百万人数据遭窃，显示0day漏洞已成为攻击者手中的常规武器。
3、勒索攻击“物理断供”：勒索软件不再局限于加密数据求财，而是直接攻击能源（Colonial Pipeline）、食品（JBS Foods）、水务等关键基础设施，导致现实世界断油、断水、断粮。
4、供应链“单点爆破”：黑客通过攻陷Kaseya、Accellion、SITA等核心供应商，实现对下游数千家企业（如瑞典超市、航空客户）的“一键式”连锁打击。
5、数据泄露“全民裸奔”：T-Mobile、Facebook等巨头相继泄露数亿用户敏感数据（身份证、人脸、电话），个人隐私在黑产面前彻底透明。
2021年12月：Log4j漏洞爆发
事件经过：Apache Log4J库中的Log4Shell漏洞被公开披露，该漏洞允许远程代码执行，影响全球数百万系统。
攻击方式：漏洞利用（远程代码执行）
造成损失：成为史上最严重的软件供应链漏洞之一，全球各行业系统面临被入侵风险，修复漏洞投入大量人力物力。
2021年10月：Facebook（Meta）数据泄露
事件经过：由于API中的一个漏洞被利用，黑客在暗网论坛上出售超过5亿Facebook用户的个人数据，涉及用户包括姓名、电话号码、电子邮件地址和出生日期。虽然数据多为旧数据，但泄露规模巨大。
攻击方式：API接口漏洞利用、数据聚合
造成损失：Facebook再次陷入隐私丑闻，加剧了公众对社交媒体数据安全的不信任，为后来公司更名Meta后的品牌形象蒙上阴影。
2021年9月：T-Mobile数据泄露事件
事件经过：美国电信巨头T-Mobile遭遇大规模数据泄露，约5000万用户的敏感信息被窃取并在黑客论坛上出售。泄露的数据包括社会安全号码（SSN）、驾照信息、姓名和地址等。
攻击方式：未经授权访问、数据窃取。
造成损失：这是美国电信行业历史上最严重的数据泄露事件之一，导致用户面临极高的身份盗窃和金融诈骗风险，T-Mobile随后面临了巨额的集体诉讼和监管调查。
2021年9月：Twitch数据泄露
事件经过：全球知名游戏直播平台Twitch遭到黑客攻击，约125GB的数据被泄露，包括源代码、未发布的项目细节以及大量主播的收入信息。黑客将数据发布在4chan论坛上。
攻击方式：系统漏洞利用、数据窃取
造成损失：公司核心商业机密外泄，主播收入隐私曝光引发社区巨大争议，平台面临法律诉讼风险，暴露了互联网巨头在代码安全和访问控制上的疏漏。
2021年7月：Windows PrintNightmare漏洞危机
事件经过：微软Windows Print Spooler服务中被曝出严重的远程代码执行漏洞（CVE-2021-34527），该漏洞影响几乎所有主流Windows版本。由于该服务在域控环境中默认开启，一旦被利用，攻击者可完全控制服务器。
攻击方式：漏洞利用（远程代码执行）
造成损失：企业内网防御体系面临崩塌风险，安全团队被迫紧急禁用打印服务或进行高风险的补丁测试，全球IT运维人员陷入紧急“排雷”状态。
2021年7月：佛罗里达州水务系统攻击
事件经过：一名黑客入侵了佛罗里达州奥尔兹马尔市的水务处理系统。攻击者短暂获得了系统控制权，并试图将水中氢氧化钠（碱液）的含量提高到危险水平（从100ppm提高到11,100ppm），幸被操作员及时发现并阻止。
攻击方式：远程桌面软件入侵（使用被盗凭证）
造成损失：直接威胁城市公共饮水安全，暴露了工业控制系统（OT）与IT网络连接后的巨大风险，引发公众对关键基础设施安全的极度担忧。
2021年6月：Kaseya供应链攻击
事件经过：REvil团伙通过Kaseya的MSP平台漏洞，影响约60家Kaseya客户和1500家企业，勒索金额高达7000万美元；瑞典最大连锁超市Coop被迫关闭800家门店。
攻击方式：供应链攻击、勒索软件攻击
造成损失：全球大量企业运营中断，零售、服务等多个行业受影响，行业供应链安全风险引发广泛关注。
2021年5月：JBS Foods勒索软件攻击
事件经过：全球最大牛肉加工商JBS Foods遭受网络攻击，被迫关闭全球多个生产基地；公司向REvil勒索软件团伙支付1100万美元赎金。
攻击方式：勒索软件攻击
造成损失：全球食品供应链受冲击，相关地区肉类供应短暂紧张，企业经济损失惨重。
2021年5月：Colonial Pipeline勒索软件攻击
事件经过：黑客组织DarkSide对美国最大成品油管道运营商Colonial Pipeline发起攻击，加密其核心运营系统，迫使公司关闭系统5天；美国最大燃油管道运输公司因攻击被迫关闭管道，导致东海岸45%的燃料供应中断，美国宣布进入紧急状态；公司最终支付近500万美元赎金。
攻击方式：勒索软件攻击（通过钓鱼邮件植入恶意程序）
造成损失：美国东海岸燃料供应中断，汽油价格飙涨4%，美国总统宣布国家紧急状态，企业经济损失与行业动荡并存。
2021年3月：微软Exchange Server漏洞攻击
事件经过：黑客利用微软Exchange Server漏洞，在全球超30万台服务器上植入webshell，多个国家政府部门受影响。
攻击方式：漏洞利用、webshell植入
造成损失：大量机构数据泄露，政府部门信息安全受严重威胁，相关单位需投入大量资源进行漏洞修复与系统清理。
2021年2月：印度航空数据泄露
事件经过：黑客攻击航空数据巨头SITA系统，导致印度航空约450万名客户的个人及财务数据被窃取，泄露数据包含护照信息、信用卡号、出生日期及联系方式等敏感内容。
攻击方式：供应链攻击（通过第三方服务商渗透）、数据窃取
造成损失：大量乘客面临身份盗用与金融诈骗风险，航空公司声誉严重受损，并面临潜在的监管调查与罚款。
2021年2月：Accellion文件传输系统供应链攻击
事件经过：黑客利用Accellion旧版文件传输设备（FTA）中的零日漏洞，入侵了包括新加坡电信、新西兰储备银行、加拿大税务局在内的全球数十家机构。攻击者利用该漏洞窃取了大量敏感数据。
攻击方式：供应链攻击、零日漏洞利用
造成损失：大量金融机构、政府部门数据泄露，多家跨国企业被迫公开数据泄露事件，Accellion作为老牌文件传输服务商的信誉受到重创。
2021年12月：微软Azure日本东部地区故障
事件经过：因电力设备故障，导致Azure日本东部地区服务中断超5小时，影响大量企业客户业务。
事故原因：基础设施运维事故，电力设备故障。
造成损失：客户业务中断，微软按SLA赔付，声誉受损。
2021年12月：西安“一码通” 短短半月崩溃两次
事件经过：12月20日及次年1月4日，西安“一码通”系统在半个月内连续两次崩溃。特别是在全员核酸检测期间，系统无法显示健康码，导致检测点排起长龙。
事故原因：系统架构无法承载峰值流量。虽然有疫情压力，但从运维角度看，是缺乏有效的弹性扩容机制和流量削峰设计，系统在面对突增的并发访问时直接“熔断”。
造成损失：疫情防控关键环节“掉链子”，严重影响了城市的防疫效率和秩序。
相关事故：
2022年1月10日，广州“粤康码”崩溃。
2022年3月11日，上海“随申码”崩溃。
2021年11月：网易游戏机房过热宕机
事件经过：网易游戏机房温度过高触发报警，部分服务器过热宕机，空调重启后仍无法解决，多款游戏无法登录、断连，3小时后服务器恢复正常。
事故原因：机房制冷系统故障，温度失控。
造成损失：干扰玩家游戏体验，影响游戏运营口碑。
2021年10月：Facebook史上最严重宕机
事件经过：10月4日，Meta旗下Facebook、Instagram、WhatsApp等服务全球中断近7小时，创2008年以来最长纪录，员工门禁卡、邮箱也无法使用。
事故原因：内部运维操作失误，修改BGP路由规则时误删域名服务器IP地址块路由配置。
造成损失：影响全球数十亿用户，Facebook市值蒸发约600亿美元，险些引发第三方服务连锁崩溃。
小插曲：宕机期间，大量用户涌向了Twitter、Telegram等其他应用，又进一步导致这些应用程序的服务器崩溃。
2021年10月：微软Azure 虚拟机全球故障
事件经过：10月13日，微软Azure云服务发生长达6小时的严重中断。全球范围内的用户无法启动、创建或更新Windows虚拟机，甚至连管理界面都打不开。
事故原因：服务管理操作期间的调用故障。在进行后台维护操作时，系统内部的调用机制失效，导致控制平面（Control Plane）失灵，用户失去了对服务器的“控制权”。
造成损失：企业无法管理核心云资产，业务扩展和维护受阻，再次打击了企业对公有云稳定性的信心。
2021年10月：Roblox 历史最长宕机
事件经过：10月28日，全球热门游戏平台Roblox发生了一次长达73小时的严重宕机。作为“元宇宙”概念的代表，这次长时间的停服让数千万玩家无法登录。
事故原因：负载均衡器过载与架构瓶颈。由于平台流量激增，负责分配流量的负载均衡器不堪重负，引发了内部网络的拥塞。Roblox坚持自建数据中心而非完全上云的策略，在应对突发流量洪峰时暴露了弹性不足的问题。
造成损失：平台信誉受损，玩家流失，且引发了关于“关键业务是否该上公有云”的行业大讨论。
2021年8月：英国Telstra数据中心火灾
事件经过：澳大利亚电信巨头Telstra伦敦数据中心因UPS故障发生火灾，导致一半大楼断电，部分区域受损。
事故原因：UPS故障引发火灾，烧毁供电组件。
造成损失：严重影响依赖该数据中心的金融及企业客户业务运转。
2021年6月：Fastly 内容分发网络崩溃
事件经过：6月8日，CDN服务商Fastly出现严重故障，导致全球大量依赖其加速的网站（包括Amazon、Reddit、CNN、PayPal等）在近1小时内无法访问。
事故原因：服务配置修改触发系统漏洞。Fastly工程师在进行一项常规的“服务配置”修改时，意外触发了系统底层的一个未被发现的软件漏洞，导致其全球节点瞬间瘫痪。
造成损失：互联网“基础设施”级故障，大量主流网站同时“消失”，凸显了互联网供应链的脆弱性。
2021年5月：Salesforce 全球大规模宕机
事件经过：5月11日，全球最大的CRM服务商Salesforce遭遇长达5小时的服务中断。这次故障波及全球，导致大量销售和客服人员无法访问客户数据。
事故原因：运维人员“走捷径”引发连锁故障。一名工程师在进行配置变更时，使用了有缺陷的脚本去绕过标准流程。该脚本在重启服务器时发生超时失败，但由于自动化部署机制未停止后续操作，导致故障在各个数据中心不断扩散，最终压垮了系统。
造成损失：全球数百万依赖Salesforce的企业用户业务停摆，作为“云服务标杆”的可靠性形象受损。
2021年4月：美国WebNX犹他州数据中心火灾
事件经过：美国WebNX犹他州数据中心发生火灾，导致超360万个网站故障，约1.5万名客户资料受影响。
事故原因：UPS故障引发火灾，缺乏物理隔离导致火势蔓延。
造成损失：部分数据永久丢失，客户权益受损，企业声誉受创。
2021年3月：法国OVH斯特拉斯堡数据中心火灾
事件经过：3月10日，欧洲云计算巨头OVH位于法国斯特拉斯堡的数据中心发生火灾，燃烧6小时后被扑灭，4个数据中心中1座完全烧毁。
事故原因：疑似UPS故障或电力室逆变器周围湿气引发短路。
造成损失：发生起火的SBG2数据中心被完全烧毁，360万个法国政府及企业网站瘫痪，OVH面临巨额赔偿和客户流失。
数字化转型，只能是一把手项目，除此之外注定失败。
国内多数的医院数字化转型项目，都是要求信息科来推进，医院领导和业务部门实际介入很少。
开局就十分不利。
产生这样局面的底层问题，在于两个：
1、组织架构老化
与欧美通常会有专业的CIO或CTO，中国多数医院的信息部门，受到的重视程度不够。
医院的信息科，其实主要就是一个运维部门，在医院组织架构中处于后勤部门一类。
这个组织架构已经几十年没变了，很难适应现代化的运营管理方法。
2、医院缺乏懂信息化的人才
国内多数的医院，十分缺乏懂业务、懂管理、懂IT技术的综合性管理人才。
直接导致了医院管理部门，与实际执行部门之间的脱节。
这样的人才不是没有，而是很稀少，且集中在顶级的那几家。
如果医院有这样的人，医院那真是捡到宝了。
再看看，中国多数医院信息科的现状（非顶级医院）：
1、相对业务科室是很弱势的
对于大科室、大专家和大主任，沟通的时候处于绝对的劣势地位，几乎没有任何话语权
2、人员数量和质量不匹配
信息科的人员，主要是桌面和运维人员，一般数量很少。
多数人员，对现代化的技术缺少理解和一手落地经验，难以挑起技术变革的大梁。
3、资源投入严重不足
效益好的医院：对比软件和安全的投入，多数医院仍倾向于基建和采购设备，因为会带来新的收入。
效益差的医院：绩效发放已经很困难，就更不愿意在这方面投入更多的资源。
加之多数医院都是风险厌恶型号机构，就更难有人愿意去做这种变革了。
那一般项目是如何落地的呢？
信息科协调不到院内资源，根本无法推动大刀阔斧的改革，没法动里子。
就只能借助院外资源，也就是厂商，做做面子。
但厂商和医院是很难平衡利益关系的：厂商利润很低，急着上线验收，医院如果再缺乏正确引导，很难有好的结果。
最后结果，同一口径，骂厂商无能。
一、上周帮老婆大人把MacOS从Mojave升级到了Catalina，然后悲剧发生了。
任何需要截屏、屏幕共享或屏幕录制的应用都不能使用了，具体表现为：
1、配置-》安全与隐私里，多了一个选项”屏幕录制/Screen Recording”，里面列表是空的。
2、快捷键录屏是可以的
3、打开QuickPlayer，录制屏幕，提示之前禁用过屏幕录制，要求去修改权限；但由于列表是空的，根本无法做任何操作
4、其他APP，如微信、腾讯会议什么的，提示要增加权限，但“屏幕录制”里还是空的。
二、网上找了一下，无论国内国外，都有一些用户遇到了这个问题。尝试了一些建议的方法，搞不定。
#正常模式下，显示失败 sudo tccutil reset ScreenCapture #恢复模式下，显示成功，重启后无效 tccutil reset ScreenCapture
三、于是打电话给Apple，一位妹子远程视频帮忙处理了很久，把能重置配置的方式都用了，还是不行。最后建议我重装系统。
四、重装，没任何变化。
五、把系统升级到了Big Sur，好歹有了一点儿进展：
1、配置-》安全与隐私里，”屏幕录制/Screen Recording”，里面列表是空的，但是新增任何APP都无效
2、快捷键录屏是可以的
3、QuickPlayer录制屏幕是可以的
4、其他APP，如微信、腾讯会议什么的，提示要增加权限，但“屏幕录制”里还是空的。
六、找了好长时间，最后终于解决了，步骤如下：
1、重启系统，听到提示音时，按下Command+R，进入恢复模式
2、恢复模式下，开启Terminal，禁用SIP服务 (system integrity protection)
csrutil disable
3、重启系统，进入正常模式，重命名tcc.db文件
sudo mv /Library/Application\ Support/com.apple.TCC/TCC.db /Library/Application\ Support/com.apple.TCC/TCC.db.bak
4、重启系统，进入恢复模式
5、恢复模式下，开启Terminal，启用SIP服务 (system integrity protection)
csrutil enable
6、重启系统，进入正常模式
7、你会发现问题解决了
整体来说，这应该是MacOS升级的一个Bug，出现频率并不高，而且横跨两个大版本至今没有解决。
（也可以这么说，Big Sur解决问题的方式只是把QuickTime加白名单了，根本没有解决根本问题；或者说解决问题的Apple程序员可能根本没有定位到问题产生的原因）
我自己解决这个问题花费了4个小时以上，如果没有编程经验的普通用户遇到，估计只能格式化重装了，希望Apple可以出个工具，解决此类问题，节约大家的时间。
当时看到《阿里巴巴Java编码规范》时，我感觉这里面说的不是大家都该知道的事情吗？真有必要汇总个规范出来？
出来混，总要还的，最近在老项目上就遇到了。
我们有两个服务，遗留项目，代码写的实在是不敢恭维。
用量其实不大，或者说偏小，但很默契的每两周挂一次，到今天是第三次了。
第一次OOM（没定位到根本问题）：
K8S网络组件异常，DNS解析失败，和架构一起排查后，发现问题如下：
1、系统原来使用过RabbitMQ，后来代码注释了
2、但POM中，还是有MQ的引用，别的不会做，但会启动MQ的监听
3、结果有一天K8S网络组件异常，DNS解析失败
4、MQ的心跳包瞬间起了几千个线程，连接找不到的MQ Server
5、服务挂了
推断的问题链路为：
DNS无法解析-》MQ心跳包不断起线程，而且没有连接池-》线程耗尽内存-》OOM-》服务挂掉
解决方法：
在POM中，干掉了MQ的引用，以为问题被修复了。
第二次OOM（大意了）：
1、表现仍是K8S网络组件异常，DNS解析失败
2、架构感觉容器DNS解析不了应该运维去查
3、只好拉上运维查，运维也比较给力，很快把日志给出来了
4、但是系统OOM时，并没有生成镜像，架构建议添加JVM参数，结果和运维排查后发现JVM参数已经加了，OOM应该有Dump啊
5、最后的结论是，非常规问题，等下次发生再解决
6、这个时候，已经感觉怪怪的了，问题根源根本没有找到啊，但大家都忙着机房搬迁，就没能跟下去（我的问题）
推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题
解决方法：
碰运气，等下一次OOM生成Dump文件？我当时咋想的呢
第三次OOM（真的解决问题了吗？）：
1、感觉不对劲啊，为什么总是两周挂，于是拉取了日志
2、日志上没看出什么来
3、仍然没有OOM的Dump
4、jstack一看线程，傻眼了，一堆线程在waiting on condition
5、赶快看相关源码，居然是用了Excutor，然后线程和队列都是默认的
6、你懂的，线程数和队列默认几乎都是无限的，参数设置错误，导致线程池根本不会服用原来的工作线程
7、服务挂掉是早晚的事情
推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题
解决方法：
修改Executor默认配置
咋说呢，再次认识到规范强制推行也是必要的，全靠人的个人水平，是不行的。他们的规范，恐怕也是各种坑汇总成的结晶吧。
前几天，突然收到报修，一个文件接收服务突然宕了。
我们运维同事很快就进行了重启，此时怪异的事情发生了：
重启服务后，服务一会儿就没响应了，端口可以通，文件全部上传失败，没有任何异常日志输出。
那就排查吧：
1、PG数据库连接正常，无死锁，表空间正常，数据查询秒回
2、服务配置几个月都没人改过，CPU、内存、存储、IO、网络，全部正常
3、上传客户端日志输出，显示其工作正常
4、只有文件接收服务，没有响应，也没有日志输出
初步判断，文件接收服务出问题了。
于是，新开一个云主机，重新安装服务，仍然无响应。
然后，拷贝了一个正常工作的主机，修改配置后，仍然无响应。
来来回回折腾了几个小时，还是不行。
无奈之余，试了一下向PG数据库插入数据，我去，几十秒都没有响应。
赶快问DBA，原来是做了高可用，主从库数据同步，从库异常了，导致主库可读不可写。
众人皆表示无奈，重启从库，问题解决。
其实，一开始就排查数据库了，但由于是生产库，只试过查询，没有试过写入。
但是，我们都大意了：
1、服务日志，输出不够详细，就算DEBUG打开，也不知道数据进行到哪一步了，这个最坑
2、没有正确的设置超时时间，原因是接收文件后，写入数据库一直在等待，服务日志没有任何数据库异常
3、数据库监视软件，只做了主库监视，根本没做从库监视
4、数据库主从配置，本应该是异步，但现在配置成了同步
5、没有监视主从库同步的情况
6、生产库，不敢轻易进行写操作，只看了查询效率及死锁，没有看慢语句
就这样一个小问题，绕过了层层监控机制，让问题排查十分困难，花费了大量的人力。
反思起来，如果只是为了记录日志而记录日志，但日志不能反应服务状态，那不如不记；如果只是为了监控而监控，但监控不到位，那不如不监控。
我们日常做事情，也是同样的道理，细节是魔鬼，把该把控的把控好了，才能提升效率，得到想要的结果。
最近到新公司，接手了几十个老项目。由于项目特殊需要，需要快速将一个模块的单元测试覆盖率提升到80%以上。
怀着忐忑的心情看了一下，该模块居然还有一个单元测试，整体覆盖率为0，欲哭无泪啊。
手工写是来不及了，那就想办法自动生成吧。找了一下，最终决定采用EvoSuite。
EvoSuite有多种方式可以配置，包括命令行模式、Maven插件模式以、Eclipse插件模式、IDEA插件模式等。
一、maven模式
1、修改POM文件，在对应位置添加相关内容
<properties>
<evosuiteVersion>1.0.6</evosuiteVersion>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.evosuite</groupId>
<artifactId>evosuite-standalone-runtime</artifactId>
<version>${evosuiteVersion}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<versionRange>[2.5,)</versionRange>
<goals>
<goal>prepare</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.evosuite.plugins</groupId>
<artifactId>evosuite-maven-plugin</artifactId>
<version>${evosuiteVersion}</version>
<executions>
<execution>
<goals>
<goal>prepare</goal>
</goals>
<phase>process-test-classes</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<properties>
<property>
<name>listener</name>
<value>org.evosuite.runtime.InitializingListener</value>
</property>
</properties>
</configuration>
</plugin>
<!--plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>.evosuite/evosuite-tests</source>
</sources>
</configuration>
</execution>
</executions>
</plugin-->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
2、生成单元测试
mvn -DmemoryInMB=4000 -Dcores=4 evosuite:generate test #生成的单元测试在 #.evosuite/best-tests #拷贝到正确的路径就可以了
二、命令行模式
1、下载evosuite-1.0.6.jar包
2、收集项目依赖，把evosuite-1.0.6.jar也放入target/dependency文件夹
mvn dependency:copy-dependencies
3、生成单元测试
cd target/dependency java -jar evosuite-1.0.6.jar -help java -Duse_separate_classloader=false -jar evosuite-1.0.6.jar -projectCP YOUR_CLASS_PATH -generateSuite -target ..\classes #生成的单元测试在 #target/dependency/evosuite-tests #拷贝到正确的路径就可以了
三、Eclipse插件模式
在eclipse中安装evosuite插件，需要额外的插件地址：
http://www.evosuite.org/update
四、单元覆盖率
1、插件安装
在eclipse中搜索并安装EclEmma Java Code Coverage插件，直接搜索即可
2、修改class loader配置
#默认使用单独的class loader，覆盖率会为0 separateClassLoader = true #全局替换为 separateClassLoader = false
3、然后在项目上，右键，Coverage as-》JUnit Test
就可以看到覆盖率了哦。
我试过两个项目，一个简单的项目，覆盖率为95以上。
一个复杂一些的Web项目，覆盖率仅为30%左右。
五、总结
生成的单元测试，实际上没有什么维护性，如何用于生产环境，待探索。
本节采用单机环境，搭建TiDB测试环境。
全程云环境部署，操作系统为CentOS7.6，用户为root。
1、修改ssh配置
# 提高连接数 vi /etc/ssh/sshd_config MaxSessions 20 #重启sshd service sshd restart
2、安装tidb
# 系统更新 yum -y update # 安装tidb源 curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh # 安装tiup cluster source .bash_profile tiup cluster
3、新建cluster配置文件
# 新建配置文件 vi mytidb.yaml # # Global variables are applied to all deployments and used as the default value of # # the deployments if a specific deployment value is missing. global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" # # Monitored variables are applied to all the machines. monitored: node_exporter_port: 9100 blackbox_exporter_port: 9115 server_configs: tidb: log.slow-threshold: 300 tikv: readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true pd: replication.enable-placement-rules: true tiflash: logger.level: "info" pd_servers: - host: 192.168.1.111 tidb_servers: - host: 192.168.1.111 tikv_servers: - host: 192.168.1.111 port: 20160 status_port: 20180 - host: 192.168.1.111 port: 20161 status_port: 20181 - host: 192.168.1.111 port: 20162 status_port: 20182 tiflash_servers: - host: 192.168.1.111 monitoring_servers: - host: 192.168.1.111 grafana_servers: - host: 192.168.1.111
4、应用cluster
#应用配置文件
tiup cluster deploy mytidb v4.0.0 ./mytidb.yaml --user root -i hwk8s.pem
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster deploy mytidb v4.0.0 ./mytidb.yaml --user root -i hwk8s.pem
Please confirm your topology:
TiDB Cluster: mytidb
TiDB Version: v4.0.0
Type Host Ports OS/Arch Directories
---- ---- ----- ------- -----------
pd 192.168.1.111 2379/2380 linux/x86_64 /tidb-deploy/pd-2379,/tidb-data/pd-2379
tikv 192.168.1.111 20160/20180 linux/x86_64 /tidb-deploy/tikv-20160,/tidb-data/tikv-20160
tikv 192.168.1.111 20161/20181 linux/x86_64 /tidb-deploy/tikv-20161,/tidb-data/tikv-20161
tikv 192.168.1.111 20162/20182 linux/x86_64 /tidb-deploy/tikv-20162,/tidb-data/tikv-20162
tidb 192.168.1.111 4000/10080 linux/x86_64 /tidb-deploy/tidb-4000
tiflash 192.168.1.111 9000/8123/3930/20170/20292/8234 linux/x86_64 /tidb-deploy/tiflash-9000,/tidb-data/tiflash-9000
prometheus 192.168.1.111 9090 linux/x86_64 /tidb-deploy/prometheus-9090,/tidb-data/prometheus-9090
grafana 192.168.1.111 3000 linux/x86_64 /tidb-deploy/grafana-3000
Attention:
1. If the topology is not what you expected, check your yaml file.
2. Please confirm there is no port/directory conflicts in same host.
Do you want to continue? [y/N]: y
+ Generate SSH keys ... Done
+ Download TiDB components
- Download pd:v4.0.0 (linux/amd64) ... Done
- Download tikv:v4.0.0 (linux/amd64) ... Done
- Download tidb:v4.0.0 (linux/amd64) ... Done
- Download tiflash:v4.0.0 (linux/amd64) ... Done
- Download prometheus:v4.0.0 (linux/amd64) ... Done
- Download grafana:v4.0.0 (linux/amd64) ... Done
- Download node_exporter:v0.17.0 (linux/amd64) ... Done
- Download blackbox_exporter:v0.12.0 (linux/amd64) ... Done
+ Initialize target host environments
- Prepare 192.168.1.111:22 ... Done
+ Copy files
- Copy pd -> 192.168.1.111 ... Done
- Copy tikv -> 192.168.1.111 ... Done
- Copy tikv -> 192.168.1.111 ... Done
- Copy tikv -> 192.168.1.111 ... Done
- Copy tidb -> 192.168.1.111 ... Done
- Copy tiflash -> 192.168.1.111 ... Done
- Copy prometheus -> 192.168.1.111 ... Done
- Copy grafana -> 192.168.1.111 ... Done
- Copy node_exporter -> 192.168.1.111 ... Done
- Copy blackbox_exporter -> 192.168.1.111 ... Done
+ Check status
Deployed cluster `mytidb` successfully, you can start the cluster via `tiup cluster start mytidb`
#启用cluster
tiup cluster start mytidb
Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster start mytidb
Starting cluster mytidb...
+ [ Serial ] - SSHKeySet: privateKey=/root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa, publicKey=/root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa.pub
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [Parallel] - UserSSH: user=tidb, host=192.168.1.111
+ [ Serial ] - ClusterOperate: operation=StartOperation, options={Roles:[] Nodes:[] Force:false SSHTimeout:5 OptTimeout:60 APITimeout:300 IgnoreConfigCheck:false RetainDataRoles:[] RetainDataNodes:[]}
Starting component pd
Starting instance pd 192.168.1.111:2379
Start pd 192.168.1.111:2379 success
Starting component node_exporter
Starting instance 192.168.1.111
Start 192.168.1.111 success
Starting component blackbox_exporter
Starting instance 192.168.1.111
Start 192.168.1.111 success
Starting component tikv
Starting instance tikv 192.168.1.111:20162
Starting instance tikv 192.168.1.111:20161
Starting instance tikv 192.168.1.111:20160
Start tikv 192.168.1.111:20162 success
Start tikv 192.168.1.111:20161 success
Start tikv 192.168.1.111:20160 success
Starting component tidb
Starting instance tidb 192.168.1.111:4000
Start tidb 192.168.1.111:4000 success
Starting component tiflash
Starting instance tiflash 192.168.1.111:9000
Start tiflash 192.168.1.111:9000 success
Starting component prometheus
Starting instance prometheus 192.168.1.111:9090
Start prometheus 192.168.1.111:9090 success
Starting component grafana
Starting instance grafana 192.168.1.111:3000
Start grafana 192.168.1.111:3000 success
Checking service state of pd
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:37 CST; 13s ago
Checking service state of tikv
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:38 CST; 12s ago
Checking service state of tidb
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:42 CST; 9s ago
Checking service state of tiflash
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:45 CST; 5s ago
Checking service state of prometheus
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:47 CST; 4s ago
Checking service state of grafana
192.168.1.111 Active: active (running) since Thu 2020-07-02 11:38:47 CST; 4s ago
+ [ Serial ] - UpdateTopology: cluster=mytidb
Started cluster `mytidb` successfully
5、查看cluster状态
#查看cluster清单 tiup cluster list Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- mytidb tidb v4.0.0 /root/.tiup/storage/cluster/clusters/mytidb /root/.tiup/storage/cluster/clusters/mytidb/ssh/id_rsa #查看cluster详情 tiup cluster display mytidb Starting component `cluster`: /root/.tiup/components/cluster/v1.0.7/tiup-cluster display mytidb TiDB Cluster: mytidb TiDB Version: v4.0.0 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 192.168.1.111:3000 grafana 192.168.1.111 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 192.168.1.111:2379 pd 192.168.1.111 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379 192.168.1.111:9090 prometheus 192.168.1.111 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 192.168.1.111:4000 tidb 192.168.1.111 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 192.168.1.111:9000 tiflash 192.168.1.111 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000 192.168.1.111:20160 tikv 192.168.1.111 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 192.168.1.111:20161 tikv 192.168.1.111 20161/20181 linux/x86_64 Up /tidb-data/tikv-20161 /tidb-deploy/tikv-20161 192.168.1.111:20162 tikv 192.168.1.111 20162/20182 linux/x86_64 Up /tidb-data/tikv-20162 /tidb-deploy/tikv-20162
6、mysql客户端操作tidb
#安装源 wget https://repo.mysql.com//mysql80-community-release-el7-3.noarch.rpm rpm -Uvh mysql80-community-release-el7-3.noarch.rpm #安装mysql客户端 yum install mysql-community-client.x86_64 #登录tidb mysql -h 192.168.1.111 -P 4000 -u root #和普通mysql操作区别很小
7、查看tidb管理界面
# 性能监控 http://192.168.1.111:3000 admin/admin # 管理界面 http://192.168.1.111:2379/dashboard root/空
本节用HTTP方式读写InfluxDB数据。
1、InfluxDB API路径
| Endpoint | Description |
| /debug/pprof | Generate profiles for troubleshooting |
| /debug/requests | Track HTTP client requests to the /write and /query endpoints |
| /debug/vars | Collect internal InfluxDB statistics |
| /ping | Check the status of your InfluxDB instance and your version of InfluxDB |
| /query | Query data using InfluxQL, manage databases, retention policies, and users |
| /write | Write data to a database |
2、ping服务状态
curl -i 'http://localhost:8086/ping' HTTP/1.1 204 No Content Content-Type: application/json Request-Id: ff6febe5-bb85-11ea-8060-fa163e4dc996 X-Influxdb-Build: OSS X-Influxdb-Version: 1.8.0 X-Request-Id: ff6febe5-bb85-11ea-8060-fa163e4dc996 Date: Wed, 01 Jul 2020 10:31:17 GMT
3、查看并新建数据库
curl -i -XPOST http://localhost:8086/query --data-urlencode "q=show databases"
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: 4eddc157-bb86-11ea-8061-fa163e4dc996
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.8.0
X-Request-Id: 4eddc157-bb86-11ea-8061-fa163e4dc996
Date: Wed, 01 Jul 2020 10:33:31 GMT
Transfer-Encoding: chunked
{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["_internal"],["NOAA_water_database"]]}]}]}
curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb"
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: 05a455eb-bb89-11ea-8062-fa163e4dc996
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.8.0
X-Request-Id: 05a455eb-bb89-11ea-8062-fa163e4dc996
Date: Wed, 01 Jul 2020 10:52:56 GMT
Transfer-Encoding: chunked
{"results":[{"statement_id":0}]}
4、写入数据
curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1422568543700000000' HTTP/1.1 204 No Content Content-Type: application/json Request-Id: 171405ad-bb8a-11ea-8063-fa163e4dc996 X-Influxdb-Build: OSS X-Influxdb-Version: 1.8.0 X-Request-Id: 171405ad-bb8a-11ea-8063-fa163e4dc996 Date: Wed, 01 Jul 2020 11:00:35 GMT curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server02,region=asia-east value=0.67 1422568543700000000 > cpu_load_short,host=server02,region=us-west value=0.55 1422568543900000000 > cpu_load_short,host=server01,region=asia-east value=2.0 1422568543900000000' HTTP/1.1 204 No Content Content-Type: application/json Request-Id: 1ad799eb-bb8a-11ea-8064-fa163e4dc996 X-Influxdb-Build: OSS X-Influxdb-Version: 1.8.0 X-Request-Id: 1ad799eb-bb8a-11ea-8064-fa163e4dc996 Date: Wed, 01 Jul 2020 11:00:41 GMT
5、查询数据
# curl双引号里面支持转义符、支持变量
# curl单引号里面不支持转义符、不支持变量
curl -i -XPOST 'http://localhost:8086/query?pretty=true&db=mydb' --data-binary "q=select * from cpu_load_short where \"region\"='us-west'"
HTTP/1.1 200 OK
Content-Type: application/json
Request-Id: d976bd19-bb8c-11ea-8076-fa163e4dc996
X-Influxdb-Build: OSS
X-Influxdb-Version: 1.8.0
X-Request-Id: d976bd19-bb8c-11ea-8076-fa163e4dc996
Date: Wed, 01 Jul 2020 11:20:20 GMT
Transfer-Encoding: chunked
{
"results": [
{
"statement_id": 0,
"series": [
{
"name": "cpu_load_short",
"columns": [
"time",
"host",
"region",
"value"
],
"values": [
[
"2015-01-29T21:55:43.7Z",
"server01",
"us-west",
0.64
],
[
"2015-01-29T21:55:43.9Z",
"server02",
"us-west",
0.55
]
]
}
]
}
]
}