从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等。
成都创新互联专注于崇阳网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供崇阳营销型网站建设，崇阳网站制作、崇阳网页设计、崇阳网站官网定制、小程序制作服务，打造崇阳网络公司原创品牌,更为您提供崇阳网站排名全网营销落地服务。
CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。
CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。
从kubernetes官方提供的 coredns.yml 文件中，不难看出coredns服务配置至少需要一个ConfigMap、一个Deployment和一个Service共3个资源对象。ConfigMap coredns 主要配置文件Corefile的内容：
其中主要有二个地方来解析配置
1、这段配置的意思是cluster.local后缀的域名都是kubernetes内部域名，coredns会监控service的变化来修改域名的记录
2、如果coredns没有找到dns记录，则去找 /etc/resolv.conf 中的 nameserver 解析
接下来使用一个带有nslookup工具的Pod来验证DNS服务能否正常工作：
通过nslookup进行测试。
查找defaul命名空间存在的ng-deploy-80服务
如果某个Service属于不同的命名空间，那么在进行Service查找时，需要补充Namespace的名称，组合成完整的域名。下面以查找kubernetes-dashboard服务为例，
众所周知, DNS 服务器用于将域名转换为 IP (具体为啥要转换建议复习下 7 层网络模型). Linux 服务器中 DNS 解析配置位于 /etc/resolv.conf , 在 Pod 中也不例外,
DNS 策略可以逐个 Pod 来设定。当前kubernetes支持这4中DNS 策略
如果我们不填dnsPolicy, 默认策略就是 ClusterFirst 。
kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。配置: 它的 nameserver 就是指向 coredns 的
k8s里面有4种DNS策略， 而coredns使用的DNS策略就是Default， 这个策略的意思就是继承宿主机上的/etc/resolve.conf, 所以coredns Pod 里面的/etc/resolve.conf 的内容就是宿主机上的内容。
在集群中 pod 之间互相用 svc name 访问的时候，会根据 resolv.conf 文件的 DNS 配置来解析域名，下面来分析具体的过程。
pod 的 resolv.conf 文件主要有三个部分，分别为 nameserver、search 和 option。而这三个部分可以由 K8s 指定，也可以通过 pod.spec.dnsConfig 字段自定义。
nameserver
resolv.conf 文件的第一行 nameserver 指定的是 DNS 服务的 IP，这里就是 coreDNS 的
clusterIP：
也就是说所有域名的解析，都要经过coreDNS的虚拟IP 10.100.0.2 进行解析， 不论是内部域还是外部域名。
search 域
resolv.conf 文件的第二行指定的是 DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询。
比如我要在刚才那个 pod 中访问一个域名为 ng-deploy-80的服务，其进行的 DNS 域名查询的顺序是：
options
resolv.conf 文件的第三行指定的是其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走 search 域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走 search 域。K8s 中默认的配置是 5。
也就是说，如果我访问的是 a.b.c.e.f.g ，那么域名查找的顺序如下：
通过 svc 访问
在 K8s 中，Pod 之间通过 svc 访问的时候，会经过 DNS 域名解析，再拿到 ip 通信。而 K8s 的域名全称为 "service-name.namespace.svc.cluster.local"，而我们通常只需将 svc name 当成域名就能访问到 pod，这一点通过上面的域名解析过程并不难理解。
参考
（1）K8S落地实践 之 服务发现（CoreDNS）
（2）自定义 DNS 服务
（3）Kubernetes 服务发现之 coreDNS
（4）Kubernetes 集群 DNS 服务发现原理
（5）Kubernetes之服务发现和域名解析过程分析
Golang, Dartlang, 是t, 啊哥们儿~。 python 是Guido 为慢慢悠悠搞出来的一个东西。现在在Google。
Filebeat是本地文件的日志数据采集器，可监控日志目录或特定日志文件（tail file），并将它们转发给Elasticsearch或Logstatsh进行索引、kafka等。带有内部模块（auditd，Apache，Nginx，System和MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。
官方网址:
Filebeat涉及两个组件：查找器prospector和采集器harvester，来读取文件(tail file)并将事件数据发送到指定的输出。
启动Filebeat时，它会启动一个或多个查找器，查看你为日志文件指定的本地路径。对于prospector所在的每个日志文件，prospector启动harvester。每个harvester都会为新内容读取单个日志文件，并将新日志数据发送到libbeat，后者将聚合事件并将聚合数据发送到你为Filebeat配置的输出。
当发送数据到Logstash或Elasticsearch时，Filebeat使用一个反压力敏感(backpressure-sensitive)的协议来解释高负荷的数据量。当Logstash数据处理繁忙时，Filebeat放慢它的读取速度。一旦压力解除，Filebeat将恢复到原来的速度，继续传输数据。
Harvester负责读取单个文件的内容。读取每个文件，并将内容发送到the output，每个文件启动一个harvester, harvester负责打开和关闭文件，这意味着在运行时文件描述符保持打开状态。
如果文件在读取时被删除或重命名，Filebeat将继续读取文件。这有副作用，即在harvester关闭之前，磁盘上的空间被保留。默认情况下，Filebeat将文件保持打开状态，直到达到close_inactive状态
关闭harvester会产生以下结果：
1）如果在harvester仍在读取文件时文件被删除，则关闭文件句柄，释放底层资源。
2）文件的采集只会在scan_frequency过后重新开始。
3）如果在harvester关闭的情况下移动或移除文件，则不会继续处理文件。
要控制收割机何时关闭，请使用close_ *配置选项
Prospector负责管理harvester并找到所有要读取的文件来源。如果输入类型为日志，则查找器将查找路径匹配的所有文件，并为每个文件启动一个harvester。每个prospector都在自己的Go协程中运行。
Filebeat目前支持两种prospector类型：log和stdin。每个prospector类型可以定义多次。日志prospector检查每个文件来查看harvester是否需要启动，是否已经运行，或者该文件是否可以被忽略（请参阅ignore_older）。
只有在harvester关闭后文件的大小发生了变化，才会读取到新行。
注：Filebeat prospector只能读取本地文件，没有功能可以连接到远程主机来读取存储的文件或日志。
配置文件：$FILEBEAT_HOME/filebeat.yml。Filebeat可以一次读取某个文件夹下的所有后缀名为log的文件，也可以读取指定的某一个后缀名为log的文件。
配置文件详解（ ）
（1）字段解释
paths： 指定要监控的日志，目前按照Go语言的glob函数处理。没有对配置目录做递归处理，比如配置的如果是：
/var/log/* /*.log
则只会去/var/log目录的所有子目录中寻找以".log"结尾的文件，而不会寻找/var/log目录下以".log"结尾的文件。
encoding： 指定被监控的文件的编码类型，使用plain和utf-8都是可以处理中文日志的。
input_type： 指定文件的输入类型log(默认)或者stdin。
exclude_lines： 在输入中排除符合正则表达式列表的那些行。
include_lines： 包含输入中符合正则表达式列表的那些行（默认包含所有行），include_lines执行完毕之后会执行exclude_lines。
exclude_files： 忽略掉符合正则表达式列表的文件（默认为每一个符合paths定义的文件都创建一个harvester）。
fields： 向输出的每一条日志添加额外的信息，比如"level:debug"，方便后续对日志进行分组统计。默认情况下，会在输出信息的fields子目录下以指定的新增fields建立子目录，
fields_under_root： 如果该选项设置为true，则新增fields成为顶级目录，而不是将其放在fields目录下。自定义的field会覆盖filebeat默认的field。
ignore_older： 可以指定Filebeat忽略指定时间段以外修改的日志内容，比如2h（两个小时）或者5m(5分钟)。
close_older： 如果一个文件在某个时间段内没有发生过更新，则关闭监控的文件handle。默认1h。
force_close_files： Filebeat会在没有到达close_older之前一直保持文件的handle，如果在这个时间窗内删除文件会有问题，所以可以把force_close_files设置为true，只要filebeat检测到文件名字发生变化，就会关掉这个handle。
scan_frequency： Filebeat以多快的频率去prospector指定的目录下面检测文件更新（比如是否有新增文件），如果设置为0s，则Filebeat会尽可能快地感知更新（占用的CPU会变高）。默认是10s。
document_type： 设定Elasticsearch输出时的document的type字段，也可以用来给日志进行分类。
harvester_buffer_size： 每个harvester监控文件时，使用的buffer的大小。
max_bytes： 日志文件中增加一行算一个日志事件，max_bytes限制在一次日志事件中最多上传的字节数，多出的字节会被丢弃。默认是10MB。
multiline： 适用于日志中每一条日志占据多行的情况，比如各种语言的报错信息调用栈。这个配置的下面包含如下配置：
pattern： 多行日志开始的那一行匹配的pattern
negate： 是否需要对pattern条件转置使用，不翻转设为true，反转设置为false。
match： 匹配pattern后，与前面（before）还是后面（after）的内容合并为一条日志
max_lines： 合并的最多行数（包含匹配pattern的那一行），默认为500行。
timeout： 到了timeout之后，即使没有匹配一个新的pattern（发生一个新的事件），也把已经匹配的日志事件发送出去
tail_files： 如果设置为true，Filebeat从文件尾开始监控文件新增内容，把新增的每一行文件作为一个事件依次发送，而不是从文件开始处重新发送所有内容。
backoff： Filebeat检测到某个文件到了EOF之后，每次等待多久再去检测文件是否有更新，默认为1s。
max_backoff： Filebeat检测到某个文件到了EOF之后，等待检测文件更新的最大时间，默认是10秒。
backoff_factor： 定义到达max_backoff的速度，默认因子是2，到达max_backoff后，变成每次等待max_backoff那么长的时间才backoff一次，直到文件有更新才会重置为backoff。比如：
如果设置成1，意味着去使能了退避算法，每隔backoff那么长的时间退避一次。
spool_size: spooler的大小，spooler中的事件数量超过这个阈值的时候会清空发送出去（不论是否到达超时时间），默认1MB。
idle_timeout: spooler的超时时间，如果到了超时时间，spooler也会清空发送出去（不论是否到达容量的阈值），默认1s。
registry_file: 记录filebeat处理日志文件的位置的文件
config_dir: 如果要在本配置文件中引入其他位置的配置文件，可以写在这里（需要写完整路径），但是只处理prospector的部分。
publish_async： 是否采用异步发送模式（实验功能）。
具体的一个yml采集配置样例如下：该配置文件是filebeat采集数据的依据，并根据需求添加必要配置，filebeat收集日志后发往logstash，配置如下：
cd FILEBEAT_HOME
nohup ./bin/filebeat -f config/test.conf /FILEBEAT_HOME/logs/filebeat.log
后台启动filebeat，配置对应的参数
启动多个filebeat配置，新建一个目录（conf）存放多个filebeat的配置文件，
#nohup ./bin/filebeat -f conf/* /FILEBEAT_HOME/logs/filebeat.log
注意：一台服务器只能启动一个filebeat进程。
ps -ef |grep filebeat
kill -9 $pid
注意： 非紧急情况下，杀掉进程只能用优雅方式。
A、filebeat运行不成功
问题：配置文件格式有问题，配置文件遵循yml文件格式， 多或少一个空格 都会导致启动问题，可以使用cmd命令窗口到filebeat安装路径下，使用filebeat.exe –c filebeat.yml 查看报错，也可以看filebeat路径下的log文件夹中的filebeat文件
B、 filebeat第一次运行成功无数据
问题：a、路径有问题
b、运行条件设置有问题（例如只采集某个条件下的数据，文件中没有符合条件的数据，这种情况下先注释掉采集条件测试一下）
C、filebeat运行成功第一次运行后有数据，第二次无数据
问题：filebeat读取文件后会生成一个registry文件，注意windows机器中这个文件在手动启动的情况下会在filebeat安装目录下的data文件夹中，服务注册启动的情况下会在C盘下隐藏文件夹C:\ProgramData\filebeat中，删除掉这个就可以了
D、filebeat运行成功有数据，但是新添加数据不读取问题
问题：filebeat传输存在反压机制，在数据量特别大或者传输通道不通的情况下，filebeat会进行反压，暂停发送，等到数据量稳定或者数据传输通道正常的之后才会发送
Filebeat 保存每个文件的状态并经常将状态刷新到磁盘上的注册文件中。该状态用于记住harvester正在读取的最后偏移量，并确保发送所有日志行。如果输出（例如Elasticsearch或Logstash）无法访问，Filebeat会跟踪最后发送的行，并在输出再次可用时继续读取文件。
在Filebeat运行时，每个prospector内存中也会保存文件状态信息，当重新启动Filebeat时，将使用注册文件的数据来重建文件状态，Filebeat将每个harvester在从保存的最后偏移量继续读取。
每个prospector为它找到的每个文件保留一个状态。由于文件可以被重命名或移动，因此文件名和路径不足以识别文件。对于每个文件，Filebeat存储唯一标识符以检测文件是否先前已被采集过。
如果你使用的案例涉及每天创建大量新文件，你可能会发现注册文件增长过大。请参阅注册表文件太大？编辑有关你可以设置以解决此问题的配置选项的详细信息。
Filebeat保证事件至少会被传送到配置的输出一次，并且不会丢失数据。 Filebeat能够实现此行为，因为它将每个事件的传递状态存储在注册文件中。
在输出阻塞或未确认所有事件的情况下，Filebeat将继续尝试发送事件，直到接收端确认已收到。如果Filebeat在发送事件的过程中关闭，它不会等待输出确认所有收到事件。
发送到输出但在Filebeat关闭前未确认的任何事件在重新启动Filebeat时会再次发送。这可以确保每个事件至少发送一次，但最终会将重复事件发送到输出。
也可以通过设置shutdown_timeout选项来配置Filebeat以在关闭之前等待特定时间。
注意：Filebeat的至少一次交付保证包括日志轮换和删除旧文件的限制。如果将日志文件写入磁盘并且写入速度超过Filebeat可以处理的速度，或者在输出不可用时删除了文件，则可能会丢失数据。
在Linux上，Filebeat也可能因inode重用而跳过行。有关inode重用问题的更多详细信息，请参阅filebeat常见问题解答。
Logback日志切割用的是JDK里File#renameTo()方法。如果该方法失败，就再尝试使用复制数据的方式切割日志。查找该方法相关资料得知，只有当源文件和目标目录处于同一个文件系统、同volumn(即windows下的C, D盘)下该方法才会成功，切不会为重命名的后的文件分配新的inode值。也就是说，如果程序里一直保存着该文件的描述符，那么当程序再写日志时，就会向重命名后的文件中写。那么问题来了，filebeat是会一直打开并保存文件描述符的，那么它是怎么得知日志被切割这件事的呢？
如果只用当前文件描述符一路监控到天黑的话，那么当logback把日志重命名后，filebeat仍然会监控重命名后的日志，新创建的日志文件就看不到了。实际上，filebeat是通过close_inactive和scan_frequency两个参数(机制)来应对这种情况的：
(1)close_inactive
该参数指定当被监控的文件多长时间没有变化后就关闭文件句柄(file handle)。官方建议将这个参数设置为一个比文件最大更新间隔大的值。比如文件最长5s更新一次，那就设置成1min。默认值为5min。
(2)scan_frequency
该参数指定Filebeat搜索新文件的频率(时间间隔)。当发现新的文件被创建时， Filebeat会为它再启动一个 harvester 进行监控，默认为10s。
综合以上两个机制，当logback完成日志切割后(即重命名)，此时老的harvester仍然在监控重命名后的日志文件，但是由于该文件不会再更新，因此会在close_inactive时间后关闭这个文件的 harvester。当scan_frequency时间过后，Filebeat会发现目录中出现了新文件，于是为该文件启动 harvester 进行监控。这样就保证了切割日志时也能不丢不重的传输数据。(不重是通过为每个日志文件保存offset实现的)
了解软考的都知道软考有三个级别，分别是初级、中级和高级，那么问题来来，软考必须得从初级开始考吗?下面呢51CTO就来简单说一下。
这里51CTO告诉大家，不是必须的。软考的报考是没有学历，年龄等等限制，并且报考资格考试时，是可以任意选择一个报考。
但是，大家不要因为说可以任意选择，就直接往高级报名，虽然没有限制，但是它在考试难度那里隐形的设置了一条线。
一般来说，无经验者报考初级，通过的概率大，毕竟从来没接触过，当然是考初级试试自己的水平更好。
相关专业的在校大学生和工作经验比较少的朋友，建议报考中级资格考试。中级考试其实也不简单，像软件设计师、软件评测师的考试内容都会涉及到程序语言，这些如果是没有经验的初学者来考的话，难度有点太大。
高级资格考试就更难了，它的考试也是隐形的设置了门槛，像高项论文，如果你没有项目方面的工作经验，你写论文就是一大难关。高项论文如果未能详细讨论项目开发的实际经验、而是从书本知识和根据资料摘录进行讨论的，基本上就是不及格的分数。
所以，虽然在层次级别上没有限制大家，但是报考的时候大家还是要根据自己的实际情况来选择。
往低了报是没什么大问题的，顶多就是再多考一个层次级别高的证。往高了报考的，很有可能就什么也没得到，浪费了时间浪费金钱。量力而行四个字大家一定要记住!
（1）关于我的职业问题
我对自己的定位是商人，说得好听一点就是企业家，说得难听一点就有各种叫法了，重庆韬翔网络科技有限公司与上海萌优电子商务有限公司都是我创办的企业，工商官方站点可以查证，并且都做得不错。
现在的商人不比以前的商人，其实现在的商人要求是比较高的，如果能力不行，很容易把公司弄倒闭。
所以，除了商人的本职工作之外，我也深入研究了一些技术，并且在公司中，很多技术难点都是我亲自带团队解决的，常用的技术有Python、PHP、数据挖掘、容器云技术、Go语言等，因为，在前期的时候，作为新技术产业项目的创始人，不懂技术，会很吃亏的，所以最好还是根据项目需求来，需要用到什么技术，那一定要去研究，不要摆创始人的架子。像马化腾、李彦宏等前辈，其实对技术研究也是非常深的，虽然我暂时离他们的距离还非常非常远，但是也要向他们看齐啊。当然除了这些IT技术之外，我还关注运营方面的技巧与思路。
再者，由于对这些技术的研究，有幸受到了51CTO学院的邀请，并且之后挺多学员喜欢的，自然我又多了一份兼职职业，IT技术讲师，同时后面也与CSDN、极客学院、天善智能等建立了合作，都是他们机构中比较早入行的讲师，再后来与出版社合作，将这些经验整理成书，并又成了IT作家，所以现在导致了基本上每天都熬夜，因为毕竟人的精力有限，同时兼顾太多，付出的时间也会很多，我经常会在半夜回复邮件等，所以有时很可能半夜本书策划编辑以及我的好友杨福川老师便收到了我的微信信息，这些凌晨三四点发消息的事情杨哥以及很多熟悉我的朋友都应该遇到过。
其实，这么多东西，我对自己的定位就是商人，一切公司需求的核心技术我都会去研究，并且由于基础还不错，所以基本上研究进展会比较快，并且大部分时候都可以有利推动项目的进展。
所以，我不敢保证我写的，我讲的都是对的，但，都是干货。我觉得把我的经验分享给大家，大家能够真正的学到东西，那就够了，至于书籍是否完美，显然是不完美的，但也会尽力去做到更好。
（2）关于作者为什么懂那么多的问题
自己夸自己多么有能力是一件非常蠢笨的事情，所以以下我只说明一下我做到了什么，以及我为什么能够做到这些，关于我的才能怎样，我想自有时间去验证，大家也自有自己的看法。
首先，上面已经提到，我是做企业的，所以我会花更多的精力去研究市场、各种需要的技术，我是一个提倡以需求作为导向的人。我认为，如果带着需求、问题去学习研究，效果会更好，并且技术很多都是用则进，不用则废。所以如果你也在学习某一样东西，最好使用起来，比如，现在你有建站的需求，可以深入研究PHP技术以及相关框架，如果你有数据采集与数据挖掘需求，可以深入研究Python已经相关技术，如果公司需要构建服务器数据中心或者容器技术，你可以深入研究Go语言以及Docker等技术。总之，带着需求去学习，效果会更好，我也是如此，这就是为什么我需要研究多种技术的原因，并且你研究得越多，你越会发现技术之间其实是相通的，你真正精通掌握了一门技术，其他的技术很容易便能深入掌握。
其次，至于说我是全才，那就过奖了，我不是全才，我也做不了全才，我只是懂得比较多，付出得比较多而已。
我想，每个人可能会根据工作要求的必然条件、兴趣爱好的充分条件，做出相应不同的选择。
也有很多工程师在学习一门新的技术时，会担心自己所学的技术是否会越来越流行，尽量去避免学习了一个非常小众和冷门的技术。
这种担忧是可以理解的，毕竟，一门技术使用的人越多，对于早期学习这门技术的工程师来说，就有越多的好处和优势。
与此同时，如果学习了一门冷门的技术，不但英雄无用武之地，而且，在求职市场上也没有什么优势。
要问我的入门编程语言选择，我首选一定是 Python，其具体原因可以引用一位网友的回答，「学完 Python，可以上天」。
Python 流行度
如果大家身处互联网，一定能够切身地感受到 Python 语言的流行程度。Python 语言由于其简单易学、语法优美、应用领域广泛等诸多优点，俘获了大批的粉丝。
但是，拿不出确切的证据，很多开发者也无法说服自己静下心来学习，接下来我们就用数据来说话。
编程语言排行榜
首先，我们了解一下近期编程语言排行榜中，Python 语言排名的变化。TIOBE 每个月发布的编程语言排行榜是编程语言流行趋势的一个指标，每个月更新。
这份排行榜排名基于互联网上有经验的工程师、课程和第三方厂商的数量，使用搜索引擎进行计算而得，一定程度上反映了编程语言的热度。
从近三个月的排行看，Python 一直稳定在排行榜的前五名。但编程语言排行榜仅能反应 Python 语言当下的流行程度，并不能回答 Python 是否越来越流行这个问题。
不过，我们可以从 TIOBE 发布的历史数据中找到一些线索。在 2015 年 2 月份发布的 TIOBE 编程语言排行榜中，Python 还排在第 8 名的位置，短短两年半的时间，Python 语言已经蹿升到第 4 名，其上升速度不可谓不快。
Google trends
既然 TIOBE 的编程语言排行榜是根据搜索引擎得到的数据，那么，我们也可以通过搜索引擎得到 Python 的搜索指数，通过搜索指数来查看 Python 语言热度的变化。图1.1 给出了最近 4 年，Python 这个关键词的 Google 搜索指数。
图 1.1 中可以看到，从全球范围来看，Python 语言是越来越流行的，其热度超过了以往任何时候。
从中国的搜索指数来看，Python 语言已经不是越来越流行这么简单了，而是出现了爆发式的增长。2014 年以前，Python 在中国都属于小众语言，从 2014 年开始，Python 在中国越来越火爆。
一个有趣的事实是，在图 1.1 给出的 Python 搜索指数中，Python 在中国的搜索每年都会有一个非常明显的、向下的尖刺。
这个尖刺所在的时间正好与春节的时间吻合，说明春节对所有中国人都是一个重要的节日，在春节期间，很少有人还在钻研技术了。
微信搜索指数
我们再来看一下最新发布的微信搜索指数中，Python 语言的热度如何。图 1.2 给出了Python、Java、PHP 和 Ruby 的微信搜索指数对比图。
由于微信最多支持 4 个关键词进行比较，因此，我们选择了 Java、PHP、Ruby 与 Python 进行比较。
选择 Java 是因为它是一门比 Python 使用更加广泛的编程语言；选择 PHP 是因为它被认为是“世界上最好的”编程语言；选择 Ruby 是因为，它是所有编程语言中，与 Python 定位最接近的编程语言。
从图中可以看出，Python 语言和 Java 语言的微信搜索指数遥遥领先，并且，Python 语言的微信搜索指数比 Java 语言还要略高一点。
基于以上的编程语言排行榜、Google 搜索指数和微信搜索指数这几个不同的数据来源，检视了 Python 语言的流行程度。
现在，我们可以非常明确的得出一个结论——Python 语言越来越流行，而且现在非常火。
为什么 Python 语言会越来越流行
原因诸多，例如：
越来越多的工程师使用 Python 进行大数据处理。
科研工作者开始使用 Python 来进行数据分析。
系统管理员使用 Python 管理 Linux 系统。
开源的云计算平台 OpenStack 使用 Python 语言开发。
很多编程爱好者使用 Python 进行爬虫等。
但是，笔者认为，Python 语言之所以越来越流行，使用越来越广泛，主要还是得益于其自身的诸多优点。对 Python 的爱与恨，可以归集到那些不得不说的优缺点：
显著的优点
Python 语言拥有诸多的优点，以下几个优点特别显著：
简单易学：Python 语言相对于其他编程语言来说，属于比较容易学习的一门编程语言，它注重的是如何解决问题而不是编程语言的语法和结构。
正是因为 Python 语言简单易学，所以，已经有越来越多的初学者选择 Python 语言作为编程的入门语言。
例如，在浙江省 2017 年高中信息技术改革中，《算法与程序设计》课程将使用 Python 语言替换原有的 VB 语言。
语法优美：Python 语言力求代码简洁、优美。在 Python 语言中，采用缩进来标识代码块，通过减少无用的大括号，去除语句末尾的分号等视觉杂讯，使得代码的可读性显著提高。
阅读一段良好的 Python 程序就感觉像是在读英语一样，它使你能够专注于解决问题，而不用太纠结编程语言本身的语法。
丰富强大的库：Python 语言号称自带电池(Battery Included)，寓意是 Python 语言的类库非常的全面，包含了解决各种问题的类库。无论实现什么功能，都有现成的类库可以使用。
如果一个功能比较特殊，标准库没有提供相应的支持，那么，很大概率也会有相应的开源项目提供了类似的功能。合理使用 Python 的类库和开源项目，能够快速的实现功能，满足业务需求。
开发效率高：Python 的各个优点是相辅相成的。例如，Python 语言因为有了丰富强大的类库，所以，Python 的开发效率能够显著提高。相对于 C、C++ 和 Java 等编译语言，Python 开发者的效率提高了数倍。
实现相同的功能，Python 代码的文件往往只有 C、C++ 和 Java 代码的 1/5~1/3。虽然 Python 语言拥有很多吸引人的特性，但是，各大互联网公司广泛使用 Python 语言，很大程度上是因为 Python 语言开发效率高这个特点。
开发效率高的语言，能够更好的满足互联网快速迭代的需求，因此，Python 语言在互联网公司使用非常广泛。
应用领域广泛：Python 语言的另一大优点就是应用领域广泛，工程师可以使用 Python 做很多的事情。
例如，Web 开发、网络编程、自动化运维、Linux 系统管理、数据分析、科学计算、人工智能、机器学习等等。
Python 语言介于脚本语言和系统语言之间，我们根据需要，既可以将它当做一门脚本语言来编写脚本，也可以将它当做一个系统语言来编写服务。
不可忽视的缺点
Python 并不是没有缺点的，最主要的缺点有以下几个：
Python 的执行速度不够快：当然，这也不是一个很严重的问题，一般情况下，我们不会拿 Python 语言与 C/C++ 这样的语言进行直接比较。
在 Python 语言的执行速度上，一方面，网络或磁盘的延迟，会抵消掉部分 Python 本身消耗的时间；另一方面，因为 Python 特别容易和 C 结合起来。
因此，我们可以通过分离一部分需要优化速度的应用，将其转换为编译好的扩展，并在整个系统中使用 Python 脚本将这部分应用连接起来，以提高程序的整体效率。
Python 的 GIL 锁限制并发：Python 的另一个大问题是，对多处理器支持不好。如果读者接触 Python 时间比较长，那么，一定听说过 GIL 这个词。
GIL 是指 Python 全局解释器锁（Global Interpreter Lock），当 Python 的默认解释器要执行字节码时，都需要先申请这个锁。这意味着，如果试图通过多线程扩展应用程序，将总是被这个全局解释器锁限制。
当然，我们可以使用多进程的架构来提高程序的并发，也可以选择不同的 Python 实现来运行我们的程序。
Python 2 与 Python 3 不兼容：如果一个普通的软件或者库，不能够做到后向兼容，那么，它会被用户无情的抛弃了。
在 Python 中，一个槽点是 Python 2 与 Python 3 不兼容。因为 Python 没有向后兼容，给所有的 Python 工程师带来了无数的烦恼。
Python 如何上手？
了解了 Python 的整体趋势及优缺点，接下来自然是如何学习 Python？
在此笔者的建议是：
找一本浅显易懂比较好的教程。无须多种选择，仅精选一本，从头到尾看完。将教程中的案例自己亲手实践一遍。
通过实际项目练手。如果仅是纸上谈兵，可能过目就忘，所以最好是要有真实的项目做。注意，真实项目不一定非要是商业项目，例如自己动手搭建网站，其关键是要核心功能完整。
最好能找到一个已经会 Python 的人。问他一点学习规划的建议，然后在遇到卡壳的地方找他指点。这样会事半功倍。但是，要学会搜索，学会如何更好地提问。
运维要不要追赶 Python 的热潮？
Python 这么热，运维要不要追赶 Python 的热潮？现阶段，掌握一门开发语言已经成为高级运维工程师的必备技能。
不会开发，你就不能充分理解你们系统的业务流程，你就不能帮助调试、优化开发人员开发的程序，因为开发人员有的时候很少关注性能的问题。
这些问题就得运维人员来做，一个业务上线了，导致 CPU 使用过高，内存占用过大，如果你不会开发，你可能只能查到进程级别，也就是哪个进程占用这么多，然后呢? 然后就交给开发人员处理了，这样怎么体现你的价值?
其次，不会一门开发语言的运维，你就不能自己写运维平台复杂的运维工具，一切要借助于找一些开源软件拼拼凑凑。
如果是这样，那就请不要抱怨你的工资低，你的工作不受重视了，话说人家 FaceBook 一个运维工程师管 2 万台机器，运维工程师年薪十几万 USD，你以为人家是盖的呢? 哪个不是身怀绝技，开发运维兼备?
Python 可以用来做什么
在我看来，基本上可以不负责任地认为，Python 可以做任何事情。无论是从入门级选手到专业级选手都在做的爬虫，还是 Web 程序开发、桌面程序开发还是科学计算、图像处理，Python 都可以胜任。
或许是因为这种万能属性，周围好更多的小伙伴都开始学习 Python。Python 现在到底有多热呢？我觉得我们可以看以下的这 2 组数据。
Python 排名稳居前五
如上文的 Python 排行，不多说，得益于 Python 在多个领域的应用都在逐渐变热，Python 在 TIOBE 榜上已经是稳居前 5 了。
越来越多的公司在用 Python 做网站
除了大家熟悉的知乎、豆瓣，已经有越来越多的公司开始用 Python 来快速搭建网站产品。相应的，也有越来越多的公司开设了 Python Web 的职位。
根据我们的统计，目前在招的 Python Web 职位，所需技能按优先级中，Python 基础和 Django 的优先级是最高的。
具体的排序，大致可以参考以下的这张图表：
运维为什么要用 Python
Good question！！！为什么不用 PHP，JAVA， C++，Ruby？
这里我只能说，见人见智， 如果你碰巧已经掌握了除 Python 之外的其他语言，那你爱用啥用啥，如果你是一个连 Shell 都还没写明白的新手，想学个语言的话，请用 Python，为什么呢？
首先，PHP 是跟 Python 比的最多的，其实他俩根本就不用比，为什么呢? 两个语言适用性不同，PHP 主要适用于 Web 开发，可以迅速的做出中小型，轻量级的 Web 网站。
但后端嘛，基本还是要借助其它语言，借助什么语言呢？Shell？Python？呵呵。而 Python 呢，是个综合语言，前后端都可以，单拿出来比 Web，也一点不比 PHP 差，但为什么 Web 方向上 PHP 比 Python 要火？
先入为主嘛，PHP 90 年代诞生就是做 Web 的，Python 2000 年后才出现 Web 框架，但论优秀程度上，Python 的 Web 框架基本上出其无左，至少是跟 PHP 比。
搞个运维小平台，用 Java 真心没啥必要，在我看来，Java 就是稳定的中年男人，稳定、成熟、秃顶，而 Python 代表的就是青春，简洁、快、干净、帅!
C++/C，这个嘛，我只能说，如果你会了 Python，又会 C 的话，那你会更吃香，但是不会 C 的话，其实也无大碍。但对新手来讲，不建议把 C 做为第一门语言开始学习，为什么呢？打击自信心…呵呵，你懂的。
Ruby，日本开发的，还不错，风格跟 Python 有点像，因为 Ruby on rails 出了名，国外用的比较多，国内，放心吧！没戏，Python 已经把它的想象空间都占死了。
当然还有新的语言 GO，有些搞运维的看见做开发的人员搞 GO，也想凑热闹，觉得是未来，我想说，别没事跟风，GO 再成功，也不会变成运维开发语言。
一个博士讲过一句话，他说：程序效率高低，80% 都是写程序的人决定了，语言本身就占 20%。
所以下次有人再说 Python 效率低的时候，请让他先回去自己检查下自己的程序多了多少无用的逻辑、循环等等。
这个博士自己用 Python 写的 Web 程序，一台服务器每天能处理上亿请求，一秒并发近两万，什么 Web 框架这么牛 B？别问它是谁，它叫 tornado。
在选择使用哪一门编程语言之前，我还想提醒读者的是——“世界上只有两种编程语言，一种是天天被人吐槽但却被广泛使用的编程语言，一种则是无人问津没有存在感的编程语言”。
Python 语言作为排名第一的动态类型语言，自然有它的道理。如果我们充分了解它的优缺点，在使用的时候，取其精华去其糟粕，那么，Python 一定是工程师解决问题的一把利剑。
--来自wechat公众号《51CTO技术栈》
