• 关于

    通用自动测试系统出现问题怎么解决

    的搜索结果

回答

nginx的静态页面都进不去的话应该是OS的TCP出了问题吧,要不看看你这个服务器当前的文件描述符数量`ulimit -n`。######回复 @snailkky : 解决了没?是这个原因吗?######回复 @口口口S口口口 : 真是太感谢你了! 我现在很怀疑就是这个原因造成的,我去试试看。######回复 @snailkky : :cold_sweat:我也只是知道这个东西,或许你可以写个测试用例试一下,用Jmeter定个6000进程访问看看######一般每个进程最多允许同时打开1024个文件,这1024个文件中还得除去每个进程必然打开的标准输入,标准输出,标准错误,服务器监听socket,进程间通讯的unix域socket等文件,那么剩下的可用于客户端socket连接的文件数就只有大概1024-10=1014个左右。也就是说缺省情况下,基于Linux的通讯程序最多允许同时1014个TCP并发连接。 是这个原因造成的吗?######65535###### 负载均衡,可以先开3个nginx,9个项目。######你这种就是性能不行, 上来就是分布式, 负载均衡。 明显几千连接,资源系统资源占用不高,是什么环节出了问题。 搞分布式,负载均衡就是掩耳盗铃######回复 @天空-sky : worker_connections 我配置了65535,另外worker_processes 我配置为8######nginx 还有worker_connections配置,可以了解下###### 密集IO情况下的Nginx调优方案: nginx进程数调到CPU核数的1.5倍,并且把每个进程平均绑到每个CPU上,多出来的让Linux自动调度到空闲CPU。 突然并发的情况下,Tomcat调优方法: 调成多进程+多线程运行模式,并且空闲时保留进程不少于CPU核数的一半。 nginx和tomcat采用fastcgi方式互交。###### 我简单看了一下,服务器很正确,监控正常,你的高峰瘫痪是指?######就是很多用户进不来,我自己也进不去,加载不出来,nginx部署的另一个静态页也无法访问###### 单机的配置降一降,拆分成多节点呗。###### 使用令牌桶做限流处理###### 我更好奇你这个监控是怎么看到的,为什么我的云监控没你的这么细######额,懂了,但是你好像是升级版的,我的是免费版的! 看了下升级版的,一个月都要1099:joy:######在云服务监控-云服务器ECS,你点进去,再点单个的监控,就可以显示这个图表了。###### 光看这个不太好分析,信息量太少。首先tomcat本身支持的并发就不高,到了6000肯定是没办法支持的,即使你将你的maxThread设置为2000,以你机器的性能也无法发挥线程的优势,反而增加了CPU线程切换的资源耗费。如果流量真的有这么大,那需要考虑做集群来承载。另外如果你的应用是IO型的,可以试试tomcat的NIO方式。######我是spring boot2,tomcat默认就是nio######高版本的tomcat好像默认都是nio,那如果是这样的话,高配服务器就发挥不了它的性能,感觉挺鸡肋的。######看症状貌似你的服务器是共享实例,积分用完之后cpu占用率不能超过20%######我这个是通用型实例 不是共享型###### 看下带宽######没有,因为我也怕是带宽的问题,然后我又升级到了60M,程序也没有变化。######回复 @snailkky : 出问题的那天,带宽使用情况怎么样?有没有出现不足######现在是5M带宽,但我那天临时升级到了20M

kun坤 2020-06-07 09:02:49 0 浏览量 回答数 0

回答

一、NGINX 502错误排查 NGINX 502 Bad Gateway错误是FastCGI有问题,造成NGINX 502错误的可能性比较多。将网上找到的一些和502 Bad Gateway错误有关的问题和排查方法列一下,先从FastCGI配置入手: 1.FastCGI进程是否已经启动 2.FastCGI worker进程数是否不够 运行 netstat -anpo | grep “php-cgi” | wc -l 判断是否接近FastCGI进程,接近配置文件中设置的数值,表明worker进程数设置太少 3.FastCGI执行时间过长 根据实际情况调高以下参数值 fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; 4.FastCGI Buffer不够 nginx和apache一样,有前端缓冲限制,可以调整缓冲参数 fastcgi_buffer_size 32k; fastcgi_buffers 8 32k; 5.Proxy Buffer不够 如果你用了Proxying,调整 proxy_buffer_size   16k; proxy_buffers    4 16k; 参见:http://www.server110.com 6.https转发配置错误 正确的配置方法 server_name www.mydomain.com; location /myproj/repos { set $fixed_destination $http_destination; if ( $http_destination ~* ^https(.*)$ ) { set $fixed_destination http$1; } proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Destination $fixed_destination; proxy_pass http://subversion_hosts; } 当然,还要看你后端用的是哪种类型的FastCGI,我用过的有php-fpm,流量约为单台机器40万PV(动态页面), 现在基本上没有碰到502。 7.php脚本执行时间过长 将php-fpm.conf的<value name="request_terminate_timeout">0s</value>的0s改成一个时间 二、Nginx 413错误的排查:修改上传文件大小限制 在上传时nginx返回了413错误,查看log文件,显示的错误信息是:”413 Request Entity Too Large”, 于是在网上找了下“nginx 413错误”发现需要做以下设置: 在nginx.conf增加 client_max_body_size的相关设置, 这个值默认是1m,可以增加到8m以增加提高文件大小限制; 如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。 post_max_size = 8M upload_max_filesize = 2M 三、Nginx 400错误排查:HTTP头/Cookie过大 今天有人汇报nginx的HTTP400错误,而且这个HTTP400错误并不是每次都会出现的,查了一下发现nginx400错误是由于request header过大,通常是由于cookie中写入了较长的字符串所引起的。 解决方法是不要在cookie里记录过多数据,如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k) 若cookie太大,可能还需要调整large_client_header_buffers(默认4k),该参数说明如下: 请求行如果超过buffer,就会报HTTP 414错误(URI Too Long) nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。 ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)没有执行完毕而导致PHP-CGI进程终止。 Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到,简单来说就是没有请求到可以执行的PHP-CGI。 解决这两个问题其实是需要综合思考的,一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关,而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关。 而正确的设置需要考虑服务器自身的性能和访客的数量等多重因素。 以我目前的服务器为例子CPU是奔四1.5G的,内存1GB,CENTOS的系统,访客大概是50人左右同时在线。 但是在线的人大都需要请求PHP-CGI进行大量的信息处理,因此我将nginx.conf设置为: fastcgi_connect_timeout 300s; fastcgi_send_timeout 300s; fastcgi_read_timeout 300s; fastcgi_buffer_size 128k; fastcgi_buffers 8 128k;#8 128 fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; 这里最主要的设置是前三条,即 fastcgi_connect_timeout 300s; fastcgi_send_timeout 300s; fastcgi_read_timeout 300s; 这里规定了PHP-CGI的连接、发送和读取的时间,300秒足够用了,因此我的服务器很少出现504 Gateway Time-out这个错误。最关键的是php-fpm.conf的设置,这个会直接导致502 Bad Gateway和504 Gateway Time-out。 下面我们来仔细分析一下php-fpm.conf几个重要的参数: php-fpm.conf有两个至关重要的参数,一个是”max_children”,另一个是”request_terminate_timeout” 我的两个设置的值一个是”40″,一个是”900″,但是这个值不是通用的,而是需要自己计算的。 计算的方式如下: 如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值,这个值可以根据你服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟-30分钟都可以。由于我的服务器PHP脚本需要长时间运行,有的可能会超过10分钟因此我设置了900秒,这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。 而”max_children”这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。设置”max_children”也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右,因此我的”max_children”我设置成40个,20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内,低于我的有效内存1Gb。而如果我的”max_children”设置的较小,比如5-10个,那么php-cgi就会“很累”,处理速度也很慢,等待的时间也较长。如果长时间没有得到处理的请求就会出现504 Gateway Time-out这个错误,而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad gateway这个错误。 //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// nginx中配置php fastcgi组解决莫名其妙的502 Bad Gateway错误 一般nginx搭配php都采用这样的方式: location ~ .php$ { proxy_pass        http://localhost:9000; fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name; include        fastcgi_params; } 这个方式只能连接到一组spawn-fcgi开启的fastcgi,在服务器负载稍高时常常出现502 bad gateway错误。 起先怀疑这是php-cgi的进程开得太少,增加后仍然有反映时常有错,偶然间发现php-cgi会报出这样的错误: zend_mm_heap corrupted 看来是php-cgi在执行某些代码时有问题,以致于该线程中止。 在服务器上可能还会看到php-cgi进程在不断变少,估计是出现错误的php-cgi的进程自动退出了。 php的问题总是不太容易能解决,所以在nginx方面想想办法,nginx的好处是它总是能爆出一些稀奇古怪的做法出来。 在nginx的proxy中,规避莫名其妙错误的办法无非是proxy到一个upstream的服务器组中,然后配置 proxy_next_upstream,让nginx遇到某种错误码时,自动跳到下一个后端上。这样,应用服务器即使不稳定,但是在nginx后面就变成了稳定服务。想到nginx的fastcgi和proxy是一路东西,所以proxy能用的经验,移植到fastcgi也能跑得起来。 照着这个思路,用spawn-fcgi多开同样一组php进程,所不同的仅仅是端口: spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f php-cgi -C 100 spawn-fcgi -a 127.0.0.1 -p 9001 -u nobody -f php-cgi -C 100 然后把fastcgi的这段配置改成用upstream的方式: upstream backend { server 127.0.0.1:9000; server 127.0.0.1:9001; } location ~ .php$ { fastcgi_pass        backend; fastcgi_param   SCRIPT_FILENAME   /data/_hongdou$fastcgi_script_name; include        fastcgi_params; } 检查配置结果正确,能跑起来;同时在服务器上netstat -n|grep 9000和grep 9001都有记录,证明连接无误;在前台查阅页面,一切运行正常。 这个配置是最简单的配置,既然能连接上upstream,那么很显然upstream的一些东西都可以拿来用,比如ip_hash、weight、max_fails等。 这样的配置在单机下不知能不能共享session,没有测试,如果有问题,可以加上ip_hash,或者配置php把session存进memcached中。 然后就是fastcgi_next_upstream的配置,nginx wiki中没有介绍到这个配置,查了一下,在nginx的CHANGES中有提到,而且出生年月是和proxy_next_upstream一样的。既然如此,那就照proxy_next_upstream一样配吧。一般按默认的值error timeout就可以工作,因为php出现502错误的异常是返回的500错误,所以我把fastcgi_next_upstream定为: fastcgi_next_upstream error timeout invalid_header http_500; 通过这个配置,就可以基本杜绝任何时常性的500错误,出问题的几率会变小很多,如果客户反映仍然激烈,那么就多增加几组fastcgi进程。

sosyxg 2019-12-02 02:43:07 0 浏览量 回答数 0

问题

【精品问答】Java必备核心知识1000+(附源码)

问问小秘 2019-12-01 22:00:28 870 浏览量 回答数 1

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

回 2楼(中郁) 的帖子 支持的,您可以试试。 ------------------------- 回 5楼(赛伯传奇) 的帖子 是的,可以这么用 ------------------------- 新增centos6.5安装包,请从帖子中的链接地址下载。 ------------------------- 回 11楼(gchoujunyong) 的帖子 建议您使用ossfs,相对于cloudfs,他更稳定,功能更全。 ------------------------- 回 13楼(chinaoc) 的帖子 您好,请问您在安装过程中遇到什么问题了吗?请在论坛或者github上及时反馈,期待您能顺利使用。 您也可参考论坛其他同学做的系列教程 http://bbs.aliyun.com/read/267185.html ------------------------- 回 15楼(wanghaitaosha) 的帖子 本周会推出ftp工具,敬请期待。 ------------------------- 回 15楼(wanghaitaosha) 的帖子 ftp工具已经推出,支持window/linux/mac,敬请试用。 http://bbs.aliyun.com/read/268724.html ------------------------- 回 24楼(唐小虾) 的帖子 你的passwd-ossfs里的bucket名字是ace-files吗?access key id/secrets是对的吗? ------------------------- 回 27楼(fjyzf) 的帖子 您好,这个系统我们没有测试过。您可以下载centos6.5的包,看看是否能用。 ------------------------- 回 33楼(小马驹) 的帖子 是官方的工具。 ------------------------- 回 31楼(懂懂) 的帖子 您好,其他idc的服务器也可以使用。 ------------------------- 回 30楼(懂懂) 的帖子 您好,支持内网域名,可通过-ourl参数设置内网域名。 ------------------------- 回 32楼(吴语) 的帖子 1. 这是一个通用的工具,能让您通过普通的文件系统接口操作OSS数据。 2. 不用挂载到系统目录下,可以挂载到任何目录下,要求是您要挂载的目录下没有数据。 ------------------------- Re:回 28楼(scorpion) 的帖子 引用第29楼chinaoc于2015-12-29 07:19发表的 回 28楼(scorpion) 的帖子 : 请问  服务器开机自动运行ossfs  怎么配置? [url=http://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=747744][/url] 您好,现在已经支持通过设置fstab来开机自动加载。请重新下载安装包,安装后按wiki的说明设置。 https://github.com/aliyun/ossfs/wiki/FAQ ------------------------- 回 41楼(赛伯传奇) 的帖子 请下载最新的安装包重新安装,照着wiki操作就好了 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第51楼商务透视网于2016-01-10 16:54发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : CentOS 6.3 64bits 系统可以用吗 [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=751339][/url] 可以的,用centos6.5的安装包安装。 ------------------------- Re:回 楼主scorpion的帖子 引用第54楼dream于2016-01-15 11:03发表的 回 楼主scorpion的帖子 : 有个问题请教: 1,挂载OSS有两个域名,一个外网,一个内网,那么我们把ourl写成内网地址速度会不会快点?会影响外网用户访问吗? 2,如果绑定了域名,ourl能不能直接写绑定的域名? 望回复,谢谢! [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=753274][/url] 1. 你是在ecs上挂载吗?建议换成内网域名,速度会更快并且流量免费。不影响外网用户访问。 2. 没有测试过,但应该是可以的,你可以试试。 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第58楼302重定向于2016-01-17 01:27发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : slb下有多个ECS的话,会有这个情况 多台ECS挂着一个bucket 多台ECS写入同一个bucket的同一个文件夹 会有问题么 [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=754115][/url] 没问题,ossfs的一个主要功能是让你在不同ecs上恭喜同一个bucket。但你自己要保证不同的ecs写不同的文件。 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第62楼verdandi于2016-01-27 15:33发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : 请问:使用过挂载目录上传过文件后,日后再次挂载时是否还需要此目录为空目录? [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=757466][/url] 需要,这是操作系统mount的要求。 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第61楼dramayang于2016-01-26 21:40发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : 挂载成功。。。就是ls有点反应迟钝。 [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=757260][/url] 第一次ls会从服务器端拿meta信息,有多次网络交互,所以比较慢。第一次ls成功后,这些meta信息会被缓存在本地,以后就很快了。 ------------------------- Re:回 67楼(oss-dev) 的帖子 引用第68楼梦丫头于2016-02-16 20:22发表的 回 67楼(oss-dev) 的帖子 : 了解,有空试下,外网支持吧 [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=760496][/url] 支持的。 ------------------------- Re:回 69楼(scorpion) 的帖子 引用第70楼梦丫头于2016-02-19 23:41发表的 回 69楼(scorpion) 的帖子 : Total size: 4.2 M Installed size: 4.2 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug ....... [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=761219][/url] 您的系统中之前安装过老版本的fuse,请先用yum卸载,再重新安装ossfs ------------------------- Re:回 71楼(scorpion) 的帖子 引用第72楼梦丫头于2016-02-20 13:35发表的 回 71楼(scorpion) 的帖子 : 已经解决,原来我安装cloudfs,卸载就可以了,不过我感觉cloudfs也不错,有启动和停止 [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=761277][/url] 您使用ossfs挂载,ossfs就启动了。您umout挂载的目录,ossfs就停止了。 ------------------------- Re:回 76楼wenlujon的帖子 引用第78楼青岩云梦于2016-03-14 10:45发表的 回 76楼wenlujon的帖子 : 同问:有个问题,如果作为一个盘挂载到ecs,那么下载的时候,走的是ecs的流量吗? [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=767511][/url] 您好,ecs下载的时候,oss端是不收流量费用的,因为是内网。 ------------------------- Re:回 14楼(scorpion) 的帖子 引用第79楼梦丫头于2016-03-18 20:55发表的 回 14楼(scorpion) 的帖子 : ossfs: could not determine how to establish security credentials. 如何解决? [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=769343][/url] 您好,这个问题一般是passwd-ossfs的内容不正确,或者权限不对导致的,请按照说明重新设置。 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第94楼失忆年华于2016-06-03 21:14发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : 第一步安装:sudo yum localinstall your_ossfs_package --nogpgcheck 就出现:[root@iZ23fccstupZ ~]# sudo yum localinstall your_ossfs_package --nogpgcheck Loaded plugins: langpacks Skipping: your_ossfs_package, filename does not end in .rpm. Nothing to do ....... [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=793827][/url] 您好,your_ossfs_package只是示例。请先下载安装包文件,然后按命令安装。 ------------------------- Re:Reossfs工具发布啦,让传统软件和云端存储完美融合 引用第98楼ap2445e0d于2016-08-18 14:39发表的 Reossfs工具发布啦,让传统软件和云端存储完美融合 : Loaded plugins: langpacks Skipping: your_ossfs_package, filename does not end in .rpm. Nothing to do [url=https://bbs.aliyun.com/job.php?action=topost&tid=267052&pid=813337][/url] 把“your_ossfs_package"替换成实际的ossfs包名

scorpion 2019-12-02 01:06:58 0 浏览量 回答数 0

回答

Go 的优势在于能够将简单的和经过验证的想法结合起来,同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧,作者认为,Go 语言具备的所有这些优点,将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大,如果将所有因素都纳入考虑,没有其他语言能够像 Go 语言一样“全面开花”,在大型软件工程方面,尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的,长期以来,他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前,Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后,在编译器和垃圾收集方面拥有数十年的经验。有太多次,他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是,他们开始着手创建新的编程语言,将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下,在包含数千万行代码的大型代码库上进行协作时,就会发生真正令人痛苦的问题。这样会导致一些问题,如下: 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有,混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等,他们需要了解代码库,但也具备广泛的编码经验。依赖于许多外部库或运行时,其中一些不再以原始形式存在。在代码库的生命周期中,每行代码平均被重写 10 次,被弄得千疮百痍,而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题,有时会以使小型工程变得更麻烦为代价,例如,代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能,如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式,机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式,从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是,Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言,只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码,以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的,避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而,在其生命周期中,人们阅读代码的时间却远远超过最初编写代码所需的时间(100 倍)。例如,审查、理解、调试、更改、重构或重用代码。在查看代码时,往往只能看到并理解其中的一小部分,通常不会有完整的代码库概述。为了解释这一点,Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说,这使得错误处理编写起来更加繁琐,但是也更容易理解。 简单易学 Go 是如此的小巧而简单,以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验,培训用不了一个星期(相比于掌握其他语言需要几个月),初学者就能够理解 Go 专家编写的代码,并为之做出贡献。为了方便吸引更多的用户,Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行,允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作,而不是个人的自我表达。 在 Go(和 Python)中,所有的语言特性都是相互正交和互补的,通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题,你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时,国骂会更少,而且人们的工作可以更好地融合在一起,从而形成了一致的整体,人人都为之感到自豪,并乐于工作。这还避免了大型工程的问题,如: 开发人员认为良好的工作代码很“混乱”,并要求在开始工作之前进行重写,因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/e64418f1455d46aaacfdd03fa949f16d.png) 简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言(Java、JavaScript、Python、Ruby、C、C++)都是 20 世纪 80 年代到 21 世纪初设计的,当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的,并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现,而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式,如 Actor 模型,但是总有多个可用选项,结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核,软件必须并行化才能高效运行。Go 是在多核处理器时代编写的,并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言,计算机系统接收数据,对其进行处理(通常要经过几个步骤),然后输出结果数据。例如,Web 服务器从客户端接收 HTTP 请求,并将其转换为一系列数据库或后端调用。一旦这些调用返回,它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例: 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供(几乎无限的)并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的,因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来,面向对象的使用富有成效,并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法,并记住了这些知识。它保留了好的部分,如封装、消息传递等。Go 还避免了继承,因为它现在被认为是有害的,并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言(Java、JavaScript、Python、Ruby)都是在互联网成为当今无处不在的计算平台之前设计的。因此,这些语言的标准库只提供了相对通用的网络支持,而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的,当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题: 碎片化:总是有多个选项实现相同的功能。 膨胀:库常常实现的不仅仅是它们的用途。 依赖地狱:库通常依赖于特定版本的其他库。 未知质量:第三方代码的质量和安全性可能存在问题。 未知支持:第三方库的开发可能随时停止支持。 意外更改:第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢,但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式,但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响: 集中讨论重要主题: 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在, 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码,但如果其他人按照自己喜欢的方式格式化了代码,这么做很招人烦。 自动代码更改并不会打乱手写代码的格式,例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时,通常会有几个相互竞争的格式标准。例如,JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用,也可以只使用其中的一个。但许多 JS 项目并没有采用它们,因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中,因此只有一个标准,每个人都在使用它。 快速编译 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/8a76f3f07f484266af42781d9e7b8692.png) 对于大型代码库来说,它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java,与 Haskell、Scala 或 Rust 等更复杂的语言相比,它们的编译速度相对较快。尽管如此,当编译大型代码库时,即使是少量的缓慢也会加剧编译的延迟,从而激怒开发人员,并干扰流程。Go 的设计初衷是为了提高编译效率,因此它的编译器速度非常快,几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈,还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单,因此它被移植到许多平台,如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言(Java、JavaScript、Python 等)不同,Go 二进制文件不需要启动或预热的时间,因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外,Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码,每次运行程序时,它们还会加载大型且高度复杂的基础架构,以进行编译和优化程序。如此一来,它们的启动时间就变慢了,并且还占用了大量内存(数百兆字节)。而 Go 进程的开销更小,因为它们已经完全编译和优化,只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中,以及在开发过程中,这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈,同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍,这是因为它无需包含编译器、JIT,以及更少的运行时基础架构的原因。这些特点,在部署大型应用程序时很重要。想象一下,如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样?如果使用 Node/JVM 时,我们的 Docker 注册表就必须提供 100 个 docker 镜像,每个镜像 200MB,那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下,如果我们想每天部署 100 次的话,如果使用 Go 服务,那么 Docker 注册表只需提供 10 个 docker 镜像,每个镜像只有 20MB,共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署,从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件,并无需安装特定版本的 JVM、Node 或 Python 运行时;也不必将库下载到生产服务器上,更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是,只是将 Go 二进制文件放到服务器上,它就会在那里运行,而不用关心服务器运行的是什么。前面所提到的那些,唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库,并将所有相关代码下载(供应)到自己的代码库中。这样做有很多好处: 在使用第三方代码之前,我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样,是我们应用程序的一部分,应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方(包括私有 Git repos)获取第三方库,你就能永久拥有它们。 经过验收后,编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码,这也并不足为奇。 即使软件包存储库速度变慢,或托管包不复存在,部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易,并且可从它们带来的许多性能和安全性改进中获益。同时,由于 Go 二进制文件包含了它们需要的所有依赖项,因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件,而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中,文档对于使软件可访问性和可维护性非常重要。与其他特性类似,Go 中的文档简单实用: 由于它是嵌入到源代码中的,因此两者可以同时维护。 它不需要特殊的语法,文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中,因此每个人都使用它们。 Go linter 需要导出元素的文档,以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时,那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化,使系统更为健壮、可靠、高效,并具有开放式开发的优势,如来自许多行业的广泛支持,多个大型实体和许多用户的支持,以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然,Go 也并非完美无缺,每种技术选择都是有利有弊。在决定选择 Go 之前,有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念(如 HTTP 2 Server push 等)方面处于行业领先地位,但与 JVM 生态系统中的第三方库相比,用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素,Go 团队非常谨慎,只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后,Go 团队正在谋划对语言进行一系列更大的改进,作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿,但支持硬实时需要没有垃圾收集的技术,例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则,虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时,这些准则可能会使大型工程项目免于许多痛苦。总的来说,正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里,用于大型软件开发项目的绝佳选择。

有只黑白猫 2020-01-07 14:11:38 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站