在使用windows电脑的时候，有时候会出现，其中某一个项目是端口被其他服务占用，导致启动失败，然而又知道哪一个进程占用了这个端口，今天小编介绍一下如何查看vista系统端口占用，以及如何将这个进程杀掉，

工具/原料

• windows系统的电脑一台，

• 占用端口的应用，

方法/步骤

1. 首先是启动windows的命令窗口，按键盘上的windows+R，然后在输入框中输入cmd，既可以启动命令窗口

   

2. 进入windows命令窗口之后，输入命令，输入netstat -ano然后回车，就可以看到系统当前所有的端口使用情况。

   

3. 通过命令查找某一特定端口，在命令窗口中输入命令中输入netstat -ano |findstr "端口号"，然后回车就可以看到这个端口被哪个应用占用。

   

4. 查看到对应的进程id之后，就可以通过id查找对应的进程名称，使用命令tasklist |findstr "进程id号"

   

5. 通过命令杀掉进程，或者是直接根据进程的名称杀掉所有的进程，，在命令框中输入如下命令taskkill /f /t /im "进程id或者进程名称"

   

6. 杀掉对应的进程id或者是进程名称之后，然后再通过查找命令，查找对应的端口，现在就可以看到这个端口没有被其他应用所占用，

   

　　最近，如果谁说自己

　　用微服务搞了个云原生应用

　　准会流露出莫名的小得意

　　凭什么如此“迷之自信”？

　　因为

　　用微服务技术构建的「云原生」应用

　　对标的是

　　传统软件开发套路搞出来的应用

　　这本质是一种底层逻辑的颠覆

　　代表了“最先进”的技术方向

　　而且，是“不可逆”的大趋势

　　得嘞

　　那么今天我们就把这事讲透

　　先进在哪，如何颠覆

　　一、啥是云原生？

　　首先，云原生不是一种产品

　　有人说是方法论，有人说是框架，有人说是机制

　　...

　　Anyway，是啥不重要

　　重要的是记住它的“尿性”

　　其中，微服务

　　是云原生最重要的特征之一

　　二、啥是微服务呢？

　　微服务的理念

　　是把原来“庞然大物”般的单体软件

　　拆解成很多独立的小模块

　　这些小模块都能独立“存活”

　　每个模块都能单独完成一个功能需求

　　那么，这些小模块就叫微服务
↓

　　这种类似“乐高”的建设思路

　　经历了一个长期的演进过程

　　微服务架构演进图

　　这条技术演进路线

　　其实是“市场倒逼技术”

　　是客户需求不断升级、不断被满足的过程

　　三、用微服务构建的 云原生应用，长啥样？

　　多个微服务功能模块

　　最终“拼”成大应用

　　相互耦合又彼此功能独立

　　每个模块都可“独立维护”

　　这种玩法的好处不言而喻

　　简化、灵活、开放、松耦合

　　更符合当下企业对业务的敏捷要求

　　随时变、随需变

　　大势所趋

　　很多厂商在云上推出的产品

　　都宣称是微服务技术的云原生应用

　　让客户通过SaaS模式获取

　　这时候

　　问题出现了

　　四、大家都标榜自己是云原生 果真如此吗？

　　当然不是

　　这里谈谈啥是“假的”云原生？

　　构建一个真正的云原生应用

　　如同房子新建，从头到脚都是新的

　　打地基的时候，就要按照云原生思路

　　现有的老房子，必须“推倒重建”

　　而修修补补做法

　　如同给房子贴了一层数字化瓷砖

　　但是内核完全不同住进去也不会“舒心”

　　比如

　　云托管≠云原生

　　云托管是

　　租个云主机，就是把本地软件搬到云上

　　多租户、容器化统统没有

　　嘿嘿，还是原来那个味~

　　云改造≠云原生

　　云改造有一定的迷惑性

　　上云后做「局部」微服务装修

　　因为房子地基、主承重墙早定了

　　无法改成真·微服务

　　SO，真正的云原生是这样的

　　打地基的时候，就在云上

　　具备云原生的一切特征！

　　五、真正的云原生SaaS，长啥样？

　　一个真正基于云原生架构的平台

　　一朵庞大的微服务集群云

　　这些海量的微服务通过

　　纯SaaS模式交付给客户

　　这类客户群特征也很清晰

　　成长型企业
↓

　　六、为什么成长型客户需要

　　完全云原生、真实微服务？

　　成长型企业最大的特征是

　　“随变”随时在变，随需而变

　　因为他们处在

　　一个内外部“极速变化”的环境里

　　组织结构在变、经营方向在变

　　业务形态在变、商业模式在变

　　新业务要扩展、新区域要覆盖

　　....

　　而云原生、微服务

　　恰好是“应对随变”的强力解药

　　松耦合，让企业的选择更多

　　一个有实力的云原生SaaS

　　除了有海量的单体微服务外

　　还包括一些成熟的微服务小集群

　　比如：财务云、营销云、制造云、人力云、协同云…

　　这些微服务

　　按场景分、按行业分、按功能分

　　所以企业的选择性空间非常大

　　开箱即用，快速上线，免运维

　　IT人员不足也没关系

　　开箱就能用，拼好就能使
↓

　　性价比超级高

　　首先，不需任何硬件投入

　　仅需要PC浏览器或手机移动端即可

　　第二，企业可以按需付费

　　就像点菜下单一样

　　随意定制化组合

　　要啥选啥，一点不浪费

　　第三，节省时间成本

　　来了就吃，省去买菜、烹饪繁琐过程

　　so，创新变革成本最低

　　支撑全球化场景

　　如果是出海企业

　　或者扩张为集团化企业↓

　　弹性扩展，高并发无压力

　　比如，双十一开战

　　上线秒杀促销

　　这时候

　　微服务的特性瞬间被激发

　　瞬间拥有支撑高并发、弹性扩展能力

　　永远使用最新版本、坐享技术红利

　　SaaS还有一个好处

　　永远能用到“最新”版本的功能

　　同时也加速企业的新技术创新

　　让成本和风险更低

　　低代码开发平台实现定制化

　　真正强大的云原生SaaS平台

　　不仅能提供“标准品”

　　还能让客户快速实现“定制化”

　　通过低/零代码的方式

　　用拖拉拽的积木式配置组合

　　就能快速构建不同场景的特殊应用

　　同时能顺畅对接原系统，数据一盘棋

　　应用搭建完成后

　　还可以发布到“云市场应用商店”

　　像APP Store一样我为人人，人人为我

　　云原生也好、微服务也好

　　都只是技术创新工具

　　难得的是，将创新工具用到极致

　　将这些技术平台化、落地化

　　如今，用友携

　　而来

　　一个真正基于微服务的云原生SaaS平台

　　为广大成长型企业

　　奉上技术红利

　　拥抱「用友」，即刻「拥有」

　　↓

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.

sqlserve的ErrorLog文件有时候会碰到文件很大的情况，可能通过命令xp_readerrorlog 或 sp_readerrorlog 执行，可以加搜索文本或起止时间

--    日志查看--exec xp_readerrorlog @FileNum,@Type,@SearchText1,@SearchText2,@StartTime,@EndTime,@order--@FileNum : 日志编号--@Type : 查询类型(1:Sql Server 日志 ; 2:代理错误日志)--@SearchText1 : 搜索文本--@SearchText2 : 搜索文本(与 @SearchText1 为"与"关系)--@StartTime : 日志查询起始时间--@StartTime : 日志查询结束时间--@order : 时间排序(ASC 或 DESC)EXEC xp_readerrorlog 0,1,N'无法打开',N'dbname','2017-11-20','2017-11-30','DESC'exec sp_readerrorlog 0,1,'无法打开','dbname'

sp_readerrorlog 一共四个参数（即xp_readerrorlog的前四个参数）

使用sp_helptext可以看出,sp_readerrorlog其实就是调用的xp_readerrorlog

查询SQL Agent 当前日志信息

Exec xp_readerrorlog 0,2

另：通过存储过程sp_cycle_errorlog可以生成新的日志文件，并循环错误日志扩展编号，就如同重新启动服务时候一样。

    EXEC sp_cycle_errorlog    GO

作为一个合格的程序员，应该抱着在哪里都要加班的理想。

为了在家调试方便，老高使用frp将自己放在公司的开发机器的ssh端口开放出来了，但是配置frp客户端的过程中总是出现下面的一句话：

2019/08/30 23:42:47 [W] [service.go:82] login to server failed: EOF
EOF

开始怀疑是frp的版本问题，于是客户端和服务端都换上了最新的版本，结果还是无法解决问题，继续尝试更换端口，问题依旧。

网上搜索一圈，发现遇到login to server failed: EOF问题的人还真不少，下面看看老高是如何解决的吧！

本地抓包

开启Wireshark，选择网卡，输入过滤规则：

tcp and ip.addr==xxx.xxx.220.109

后面的那三个RST包很可疑，其中还有三个IRC协议的包，打开看一下，发现原来是认证数据。

{"version":"0.28.2","hostname":"","os":"darwin","arch":"amd64","user":"","privilege_key":"144fa23b09635f403ccd18","timestamp":1567119104,"run_id":"","pool_count":1}

服务端抓包

打开终端，输入命令

# xxxx 为frp监听端口tcpdump -i eth0  port xxxx -n

23:57:54.041136 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [S], seq 2454088299, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1598952560 ecr 0,sackOK,eol], length 0
23:57:54.041203 IP xx.xx.xx.xx.PPPP > 180.167.229.162.64674: Flags [S.], seq 2502814427, ack 2454088300, win 65160, options [mss 1460,sackOK,TS val 3508779989 ecr 1598952560,nop,wscale 6], length 0
23:57:54.171283 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [.], ack 1, win 2058, options [nop,nop,TS val 1598952691 ecr 3508779989], length 0
23:57:54.171670 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [P.], seq 1:13, ack 1, win 2058, options [nop,nop,TS val 1598952692 ecr 3508779989], length 12
23:57:54.171694 IP xx.xx.xx.xx.PPPP > 180.167.229.162.64674: Flags [.], ack 13, win 1018, options [nop,nop,TS val 3508780120 ecr 1598952692], length 0
23:57:54.171896 IP xx.xx.xx.xx.PPPP > 180.167.229.162.64674: Flags [P.], seq 1:13, ack 13, win 1018, options [nop,nop,TS val 3508780120 ecr 1598952692], length 12
23:57:54.172366 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [P.], seq 13:25, ack 1, win 2058, options [nop,nop,TS val 1598952692 ecr 3508779989], length 12
23:57:54.172391 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [R.], seq 25, ack 1, win 8224, length 0
23:57:54.301735 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [R.], seq 13, ack 1, win 8224, length 0
23:57:54.302089 IP 180.167.229.162.64674 > xx.xx.xx.xx.PPPP: Flags [R.], seq 13, ack 13, win 8224, length 0

好嘛，注意最后三个包，也是RST，而且方向刚好和我在本地抓包相反，很明显，这是受到了替身攻击！

1. frpc客户端连接会提示 login to server failed: EOF

2. 解决办法

vim your_path/frpc.ini