Day: 8 January 2019

正向代理 反向代理 透明代理 负载均衡 静态服务器 nginx的安装 【实现功能】 这篇文章将要介绍的主要内容如下： 1、配置三台服务器 2、分别在三台服务器上部署同样的服务代码 3、使用Nginx实现负载均衡 【实现思路】 我们的Nginx负载均衡器将部署在一台交互服务器上，配置与其他两台服务器的连接，所有的请求直接访问Nginx服务接口，然后Nginx负载均衡器将自行选择真实调用的服务器端口。 【开发及部署环境】 开发环境：Windows 7 x64 sp1 英文版 VisualStudio 2017 部署环境：阿里云 ECS实例 windows server 2012 x64 IIS 7.0 【所需技术】 ASP.NET WebApi2 【实现过程】 使用ASP.NET webapi2 写一个简单地返回json的接口，为了展示我们调用的是不同服务器上的接口，我们以数字形式分别生成三个接口服务，并且分别部署到三台服务器的iis中。 public IHttpActionResult GetTest() { //throw new Exception_DG_Internationalization(1001); string ip = Request.GetIpAddressFromRequest(); return OK(“Test Api . Client Ip Address is …

Read more “Nginx负载均衡及几个基本用法”

JMeter特点 适用性广泛 可以适用于多种应用，服务和协议 Web – HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …) SOAP / REST Webservices FTP Database via JDBC LDAP Message-oriented middleware (MOM) via JMS Mail – SMTP(S), POP3(S) and IMAP(S) Native commands or shell scripts TCP Java Objects 全功能的集成测试工具 支持从浏览器或本地应用程序录制，构建和调试测试计划。 跨平台 纯Java，100%的可移植性，支持从Linux，Windows，Mac OSX等操作系统运行，支持图形界面或命令行方式。 报表 多种HTML的动态报表展示测试结果。 可扩展 高度可扩展的架构，支持JSR223兼容的脚本语言，例如Groovy，BeanShell。可与Maven, Gradle和Jenkins结合使用。 压力测试示例 当前版本的JMeter为5.0，运行需要安装Java8以上的Java。下载后解压，在Windows环境可运行bin目录下的jmeter.bat。 初始图形界面 一，录制测试计划 点击初始界面中工具栏的第二个按钮开始准备录制，弹出如下界面，点击create …

Read more “JMeter压力测试工具简介”

在本文中，我们将研究深度学习、机器学习、数据分析、数据挖掘之间的差异。我们将逐一了解它们，然后讨论他们在各个方面的不同之处。先看AI知识图谱： AI知识图谱 深度学习与机器学习发展史 发展史 一、什么是机器学习？ 机器学习：抵达AI目标的一条路径 大体来讲，机器学习就是用算法真正解析数据，不断学习，然后对世界中发生的事做出判断和预测。此时，研究人员不会亲手编写软件、确定特殊指令集、然后让程序完成特殊任务，相反，研究人员会用大量数据和算法“训练”机器，让机器学会如何执行任务。 机器学习这个概念是早期的AI研究者提出的，在过去几年里，机器学习出现了许多算法方法，包括决策树算法（Decision trees）、归纳逻辑程序设计、聚类分析(Clustering)、强化学习、贝叶斯网络、Find-S算法、随机森林算法（Random forests）、人工神经网络等。正如大家所知的，没有人真正达到“强人工智能”的终极目标，采用早期机器学习方法，我们连“弱人工智能”的目标也远没有达到。 机器学习 通常，有3种类型的学习算法： 1，监督机器学习算法用于进行预测。此外，该算法搜索分配给数据点的值标签内的模式。 2，无监督机器学习算法：没有标签与数据点相关联。这些ML算法将数据组织成一组簇。此外，它需要描述其结构，使复杂的数据看起来简单，有条理，便于分析。 3，增强机器学习算法：我们使用这些算法来选择动作。此外，我们可以看到它基于每个数据点。一段时间后，算法改变其策略以更好地学习。 二、什么是深度学习？ 深度学习：实现机器学习的技术 深度学习是机器学习中一种基于对数据进行表征学习的方法。观测值（例如一幅图像）可以使用多种方式来表示，如每个像素强度值的向量，或者更抽象地表示成一系列边、特定形状的区域等。而使用某些特定的表示方法更容易从实例中学习任务（例如，人脸识别或面部表情识别）。深度学习的好处是用非监督式或半监督式的特征学习和分层特征提取高效算法来替代手工获取特征。 深度学习是机器学习研究中的一个新的领域，其动机在于建立、模拟人脑进行分析学习的神经网络，它模仿人脑的机制来解释数据，例如图像，声音和文本 任何深度神经网络都将包含三种类型的图层：输入层、隐藏层、输出层。我们可以说深度学习是机器学习领域的最新领域。这是实现机器学习的一种方式。 三、数据挖掘 数据挖掘利用各种技术与统计方法，将大量的历史数据，进行整理分析，归纳与整合，是从海量数据中“挖掘”隐藏信息，如趋势、特征及相关的一种过程。工作BI（商业智能）、数据分析、市场运营都可以做这个工作。 数据挖掘 之所以经常和机器学习合在一起讲是因为现在好多数据挖掘的工作是通过机器学习提供的算法工具实现的。例如广告的ctr预估，PB级别的点击日志在通过典型的机器学习流程可以得到一个预估模型，从而提高互联网广告的点击率和回报率；个性化推荐，还是通过机器学习的一些算法分析平台上的各种购买，浏览和收藏日志，得到一个推荐模型，来预测你喜欢的商品。 我们可以把数据挖掘理解为一种类型的工作，或工作中的某种成分，机器学习是帮助完成这个工作的方法。 统计学、数据库和人工智能共同构造了数据挖掘技术的三大支柱，许多成熟的统计方法构成了数据挖掘的核心内容。 四、数据分析 数据分析只是在已定的假设，先验约束上处理原有计算方法，统计方法，将数据转化为信息，而这些信息需要进一步的获得认知，转化为有效的预测和决策，这时就需要数据挖掘，也就是我们数据分析师系统成长之路的“更上一楼”。 数据分析 数据分析是把数据变成信息的工具，数据挖掘是把信息变成认知的工具，如果我们想要从数据中提取一定的规律（即认知）往往需要数据分析和数据挖掘结合使用。 举个例子：你有50块钱，去买菜，经过一一问价，你知道了50块钱能买多少蔬菜，能买多少肉，能吃多少天，心里得出一组信息，这就是数据分析。根据自己的偏好，营养价值，用餐时间计划，最有性价比的组合确定了一个购买方案，这就是数据挖掘。 五、机器学习与深度学习的比较 深度学习与机器学习我们使用机器算法来解析数据，从数据中学习，并根据所学知识做出明智的决策。基本上，深度学习用于创建人工“神经网络” ，可以自己学习和做出明智的决策。我们可以说深度学习是机器学习的一个子领域。 数据依赖性 性能是两种算法之间的主要关键区别。虽然，当数据很小时，深度学习算法表现不佳。这就是是深度学习算法需要大量数据才能完美理解的原因。 但是，在这种情况下，我们可以看到算法的使用以及他们手工制作的规则。上图总结了这一事实。 硬件依赖 通常，深度学习依赖于高端机器，而传统学习依赖于低端机器。因此，深度学习要求包括GPU。这是它工作中不可或缺的一部分。它们还进行大量的矩阵乘法运算。 特色工程 这是一个普遍的过程。在此，领域知识被用于创建特征提取器，以降低数据的复杂性，并使模式更加可见以学习算法的工作。虽然，处理起来非常困难。因此，这是需要非常多的专业知识和时间。 解决问题的方法 通常，我们使用传统算法来解决问题。但是，它需要将问题分解为不同的部分以单独解决它们。要获得结果，请将它们全部组合起来。 例如：让我们假设你有一个多对象检测的任务。在此任务中，我们必须确定对象是什么以及它在图像中的位置。在机器学习方法中，我们必须将问题分为两个步骤：1.物体检测、2.物体识别。 首先，我们使用抓取算法浏览图像并找到所有可能的对象。然后，在所有已识别的对象中，你将使用像SVM和HOG这样的对象识别算法来识别相关对象。 执行时间处理时间 通常，与机器学习相比，深度学习需要更多时间进行训练。主要原因是深度学习算法中有太多参数。机器学习只花需要更少的时间进行训练。 解释性 我们将可解释性作为比较两种学习技巧的因素。尽管如此，深度学习在用于工业之前仍然被认为是10次。 六、数据分析与数据挖掘的比较 数据分析只是在已定的假设，先验约束上处理原有计算方法，统计方法，将数据分析转化为信息，而这些信息需要进一步的获得认知，转化为有效的预测和决策，这时就需要数据挖掘，也就是我们数据分析师系统成长之路的“更上一楼”。 数据挖掘与数据分析两者紧密相连，具有循环递归的关系，数据分析结果需要进一步进行数据挖掘才能指导决策，而数据挖掘进行价值评估的过程也需要调整先验约束而再次进行数据分析。 数据量上：数据分析的数据量可能并不大，而数据挖掘的数据量极大。 约束上：数据分析是从一个假设出发，需要自行建立方程或模型来与假设吻合，而数据挖掘不需要假设，可以自动建立方程。 对象上：数据分析往往是针对数字化的数据，而数据挖掘能够采用不同类型的数据，比如声音，文本等。 …

Read more “AI知识图谱：机器学习、深度学习、数据分析、数据挖掘「附脑图」”

互联网概念的token认证，大抵是在RESTful API 流行后提出的，在开始token认证之前，我们先梳理下常见的互联网认证机制。 一、HTTP Basic Auth HTTP Basic Auth常见的有两种：第一种就是最常见的，即我们在登陆一些web页面时，会让我们输入用户名密码；另一种是将用户名密码信息通过base64这类算法变换成一条字符串在http请求头中增加auth字段，再传输给服务端。 这个属于最原始级的认证，缺点比较明显，存在http头中的密码信息容易被抓包获取，用户名密码后服务端后需要查询数据库里的信息，进行比对信息，这也增加了服务器的负担。 二、session+cookie模式 假设目前我们有一个查询类的web站点，不可能查询都要登陆一次，为解决一次登陆，可以在固定一段时间内都免登陆查询，就出现了session+cookie模式，该模式是第一次登陆时使用HTTP Basic Auth，认证成功后，为避免每次都到数据库里校验用户名密码信息，就在主机上存储一份登陆的session信息，在本身cookie里记录对应的session信息，cookie里同时保存expire time。 该模式优缺点都比较明显：session信息需要额外的数据库存储，例如一般需增加redis、memached等应用。在多机负载时，需要考虑session共享；但好处也是明显的，session信息统一管理，可以在服务端统一控制认证的过期时间或个别用户的过期时间。 三、简单token认证 token认证最常用的应用场景就是查询接口的调用（RESTful API），查询接口的信息在没有安全需求时，大家都可以通过get方法或post方法取得所需信息。但在有安全需要时一般需要认证后才能获取所需的信息，这时候可以通过先能过HTTP Basic Auth，HTTP Basic Auth认证完成后，服务端返回给客户端一个类似于UUID的唯一标识，我们称之为token。该token一般可以在URL或head头里加入，如以下的常见的URL模式 http://api,361way.com/getinfo?token=xxxxx 或 http://api,361way.com/getinfo?t=xxxxx ，后面再加上相应的查询信息，就可以获取到相应的数据。 token的好处是服务端不需要存储相应信息，但被不怀好意的人从中间获取到该信息时，也容易被利用，非法获取数据。 由于这个简单的token返回串里未返回相应的过期时间信息，如果想增强安全性，一般可以在服务端生成时配合时间戳生成，服务端在接收到client发来带token的信息时，先检测反解token获取时间戳信息，如果该时间戳在超过某个时间点时，就认为过期，需要重新获取。 四、OAuth认证 OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。 这个理解起来比较绕口，举个例子，如很多网站上面有qq或微信登陆接口，qq或微信提供的就是OAuth认证。OAuth虽然名字很洋气，其本质还是token认证，仔细研究下上面的话，是不是原理上和上面提到的简单token认证类似，只不过其加了几个callback函数而已 这里以douban豆瓣网调用QQ的OAuth节口为例，其调用方式如下： # 发起认证： http://www.douban.com/leadToAuthorize # 重定向到QQ认证，并指定回调： http://www.qq.com/authorize?callback=www.douban.com/callback # 返回授权码，并callback到douban http://www.douban.com/callback 五、JWT认证 JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。一个JWT实际上就是一个字符串，它由三部分组成，头部（Header）、载荷（Payload）与签名（Signature）。这里只简单说下理论，会另开博文深层讨论。 Payload里存放的是存储签发者、签发时间、过期时间、一些数据信息的JSON格式的内容。 { “iss”: “Online JWT Builder”, “iat”: 1416797419, “exp”: …

Read more “Token简介”

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。 如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。 把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述： 微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。 微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。 再强调下即： 首先对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键，即我们在进行单个应用组件设计的时候，本身在组件内部就会有很大接口的设计和定义，那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务，而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。 其次，微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说，组件超外部暴露的能力才需要发布为微服务，其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑，组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。 微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。 对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后，虽然整体架构可以松耦合和可扩展，但是如果拆分的组件越多，这些组件之间本身的集成和部署运维就越复杂。即任何一个组件，当他依赖的外部其它应用组件越多的时候，整个集成，部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量，一是增加出错概率。 原来谈组件化开发谈的最多的是单个组件的持续集成，包括配置环境集成，自动打包部署，自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成，其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路，希望能够实现开发设计到部署运维的一体化。 由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行，各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性，我们可以用虚拟机，但是当几十个进程都完全用独立的虚拟机就不现实的，而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情，每个Docker是独立的容器刚好又完全做到进程级别的隔离，资源占用率又最小，这些特点刚好满足微服务架构的开发测试和自动化部署。 前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台，按照当前微服务架构的整体思路，虽然单个服务的实现和发布仍然是在组件内部完成的，但是这些组件暴露的服务本身的调用情况，服务本身的安全，日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。 由于微服务尽量都是通过HTTP API的方式暴露出去的，因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册，服务代理，服务发布，服务简单的路由，安全访问和授权，服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构，即可以做为微服务架构下的服务管控平台。 对于这种服务管控平台，核心需要讨论的就是服务每次调用本身的消息传递，输入和输出日志是否需要记录，当前就有两种做法，一种是不记录，管理平台只负责服务注册和目录发布，安全授权，实际的服务访问仍然是两个组件之间的点对点连接完成，这种方式下整个架构下获取更高的性能，同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈；另外一种方式就是完全记录，在这种方式下就需要考虑服务管理平台本身的集群化不是，高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力，同时仅仅对核心的需要Log日志的服务进行日志记录，而其它服务只提供服务目录和访问控制即可。 ===========2016.6.8日更新，增加Chris Richardson微服务系列读书笔记 本文为阅读《Chris Richardson 微服务系列》的阅读笔记，具体原文参考：「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例 ，私信“555”有惊喜！！ 里面有另外四篇的链接，当前daocloud已经更新到第5篇事件驱动架构。 第一篇 微服务架构的优势和不足 文中强调的单体应用的场景，我在前面很多谈组件化和服务化的文章里面已经都谈到过了，即一个应用系统里面的模块没有办法做到彻底解耦，如果要实现按组件单独部署是不可能的，相互之间仍然有大量内部不可见依赖而导致了模块间无法拆分。 那么单体应用本身带来的问题主要有哪些？ 1.系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身。 2.运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。 3.无法扩展：无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是DB问题难解决 正是由于这些原因需要考虑引入微服务架构（实质仍然是单个应用本身的组件化和服务化），对于微服务文章里面有一个详细说明如下：一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种接口。有的微服务通过暴露API 被别的微服务或者应用客户端所用；有的微服务则通过网页 UI 实现。在运行时，每个实例通常是一个云虚拟机或者 Docker容器。 从这个定义和说明仍然需要做一些关键理解，即在我前面谈微服务的文章里面谈到过的，即核心的几点包括了，其一足够构成一个独立小应用（从DB到UI），其二微服务应用之间只能通过ServiceAPI进行交互，其三一般运行在云虚拟机或更轻的Docker容器上。 APIGateway，这实际上微服务架构里面的很重要的内容，其作用类似于传统企业内部的ESB服务总线，只是更加轻量和高性能来解决微服务的管控和治理问题。而对于负载均衡，缓存，路由，访问控制，服务代理，监控，日志等都属于基本的服务管控内容，也是APIGateway需要考虑的核心能力。 Scale Cube的3D模型，描述的相当好，即通过微服务架构实施后扩展性的变化。 1. Y轴：本质是应用的分解，即将传统的单体应用分解为多个微服务应用。 2. X轴：水平弹性扩展能力，即通过负载均衡来实现水平弹性扩展，但是DB问题无法解决，引入3 3. Z轴：当单个微服务应用引入了DB弹性扩展能力要解决的时候，我们引入了对数据库进行拆分和DaaS 对于微服务架构的好处前面在讲单体应用的问题的时候已经谈到了，微服务架构正好是解决这些问题。而对于微服务架构的不足，简单总结如下： 1. CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题。 2. 集成复杂：任何彻底的分解都将带来集成的复杂度，即模块在集成时候需要外部微服务模块更多的配合。 …

Read more “SOA和微服务架构的区别”

管理 Python 版本和环境的工具 p – 非常简单的交互式 python 版本管理工具。 pyenv – 简单的 Python 版本管理工具。 Vex – 可以在虚拟环境中执行命令。 virtualenv – 创建独立 Python 环境的工具。 virtualenvwrapper- virtualenv 的一组扩展。 包管理 管理包和依赖的工具 pip – Python 包和依赖关系管理工具。 pip-tools – 保证 Python 包依赖关系更新的一组工具。 conda – 跨平台，Python 二进制包管理工具。 Curdling – 管理 Python 包的命令行工具。 wheel – Python 分发的新标准，意在取代 eggs。 包仓库 本地 PyPI 仓库服务和代理。 warehouse – …

Read more “Python库整理”

1.ag：比grep、ack更快的递归搜索文件内容。 2.tig：字符模式下交互查看git项目，可以替代git命令。 私信菜鸟007哦！有惊喜大礼包！ 3.mycli：mysql客户端，支持语法高亮和命令补全，效果类似ipython，可以替代mysql命令。 4.jq: json文件处理以及格式化显示，支持高亮，可以替换python -m json.tool。 5.shellcheck：shell脚本静态检查工具，能够识别语法错误以及不规范的写法。 6.yapf：Google开发的python代码格式规范化工具，支持pep8以及Google代码风格。 7.mosh：基于UDP的终端连接，可以替代ssh，连接更稳定，即使IP变了，也能自动重连。 8.fzf：命令行下模糊搜索工具，能够交互式智能搜索并选取文件或者内容，配合终端ctrl-r历史命令搜索简直完美。 9.PathPicker(fpp):在命令行输出中自动识别目录和文件，支持交互式，配合git非常有用。 运行以下命令： git diff HEAD~8 –stat | fpp 10.htop: 提供更美观、更方便的进程监控工具，替代top命令。 11.axel：多线程下载工具，下载文件时可以替代curl、wget。 axel -n 20 http://centos.ustc.edu.cn/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso 12.sz/rz：交互式文件传输，在多重跳板机下传输文件非常好用，不用一级一级传输。 13.cloc：代码统计工具，能够统计代码的空行数、注释行、编程语言。 14.ccache：高速C/C++编译缓存工具，反复编译内核非常有用。使用起来也非常方便： gcc foo.c 改成: ccache gcc foo.c 15.tmux：终端复用工具，替代screen、nohup。 16.neovim: 替代vim。 17.script/scriptreplay: 终端会话录制。 script -t 2>time.txt session.typescript # 录制开始# your commandsexit # 录制结束 回放: scriptreplay -t time.txt session.typescript 18.you-get: 非常强大的媒体下载工具，支持youtube、google+、优酷、芒果TV、腾讯视频、秒拍等视频下载。 还有mac专有的pbcopy/pbpaste： 把命令行输出拷贝到系统粘贴板： …

Read more “20个Linux命令行外壳”