nvm的一些问题

在16年发表过一篇介绍nvm多版本npm的文章,当时写的非常有问题,今天reload .zshrc文件发现如下提示 nvm is not compatible with the npm config "prefix" option: currently set to "/Users/fabian/.nvm/versions/node/v7.6.0" Run `nvm use --delete-prefix v7.6.0` to unset it. 我就纳闷怎么会突然这种问题,经过查询资料,nvm和npm的路径不同产生冲突,而brew安装nvm的方式是最容易发生这种情况,所以解决版本很简单 brew uninstall nvm 先卸载,之后按照文档老老实实走 安装…

微服务巡礼 Spring Cloud 体系使用(四)Spring Cloud Feign

前面的文章其实已经可以简单运行一个微服务应用,有服务器发现、负载均衡、断路器。而在平时开发中,我们发现负载均衡、断路器两者必定会出现,因为每个服务都必须包含负载均衡和错误处理,既然如此的设计那肯定有更高层次的封装整合这两个框架的使用。它就是Spring Cloud Fegin,基于Netflix Feign实现,除了提供这两者的强大功能之外,它还提供一种声明式的Web服务客户端方式。 通过Feign,可帮助我们更加便捷、优雅地调用HTTP API,在Spring Cloud中,使用Feign非常简单--创建一个接口,并在接口上添加一些注解,代码就完成,同时搞定对服务提供方的接口绑定,简化在使用Spring Cloud Ribbon时自行封装服务调用客户端的开发量。 快速入门 创建一个feign-consumer的工程,pom.xml文件如下 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId&…

微服务巡礼 Spring Cloud 体系使用(三)Spring Cloud Ribbon 和Spring Cloud Hystrix

其实这两个服务是非常复杂,但由于篇幅限制和时间精力,本人这里只简单介绍如何使用,源码分析这些需要靠读者们自己领悟了。 Spring Cloud Ribbon 上一节我们说了服务注册和服务提供,现在简单说一下服务消费,通过Spring Cloud Ribbon实现,是一套基于HTTP和TCP的客户端负载均衡工具,在Netflix Ribbon基础上实现。通过它,我们能轻松将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。要注意,它仅仅是工具类框架,不必像其他服务需要独立部署,但无处不在,所有微服务之间的调用转发都是通过Ribbon实现。 负载均衡的重要性不用说,面对突发大流量,保障系统正常运行非常重要一道关卡。 我们现在实现一个简单的Ribbon服务。 惯例pom.xml配置 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId>…

微服务巡礼 Spring Cloud 体系使用(二)Spring Cloud Eureka

服务治理是微服务架构中最为核心和基础的模块,散落在各处的服务要如何才能实现互相通信,一个控制中心非常重要(虽然不可避免使注册服务过于集中化),这个中心要实现发现散落各处的服务并将这些服务调用到需要的消费者。那么先根据我们自己的想象,要是自己做个控制中心,该怎样设计。 1、发现服务 2、服务调度 3、问题处理机制 那么按照这个思路,我们来学习Spring Cloud体系下服务治理怎样做。 Spring Cloud Eureka 是Spring Cloud Netflix微服务套件中的一部分,基于Netflix Eureka做二次封装,主要负责完成微服务架构中的服务治理功能。服务治理底层有很多选择,也可以选Zookeeper、dubbo(底层也是Zookeeper)。以前业务中只有一个实例中心SOA,维护这份地址调用配置基本是复制粘贴就搞定,除了各个api项目在静态配置如果要修改SOA地址比较麻烦之外,配个携程阿波罗配置分发中心其实还好,但因为中心只有两点关系,不存在需要经过中心调用的第三点,处理相对比较容易。 然而在微服务体系下,控制中心并不做任何业务处理,如果微服务应用不断增加,各个服务之间调用情况越来越多,如果还是靠人工配置调用关系会非常容易出错,如果要做集群、水平扩展,这些情况必是大大影响工作推进,运维压力大。那么这时,一个服务中心必须出现,相比散落各处的服务,只有一个服务的运维其实已经比较轻松。…

Docker构建本地MySQL环境

MySQL构建现在非常方便,但一般会对本地环境有相当大影响,请神容易送神难。现在我们有Docker,可以非常轻松创建MySQL容器,轻松销毁,没有任何负担,而且可以将其编排成docker-compose和Dockerfile,非常快速组建集群,我们引入Docker后,的确大大提高效率。 前置开发条件 系统 MacOS High Sierra 10.13 首先,安装Docker,Docker版本没有要求,应该不同版本不会有太大区别,正常启动是这种状态 注意,在Mac上,2012以前的系列使用Docker会卡在Docker is Starting上,这是个机器的问题,建议使用2013起开始的机型,可能老旧的机器Docker不支持或者其他原因。 安装完成后,输入命令,docker -v顺利输出版本意味安装成功。 Docker的基本知识从这个链接上看即可 https://yeasy.gitbooks.io/docker_practice/content/ 看完之后,对Docker有个大致的了解。 现在让我们创建一个文件夹mysql5.7,这次我们使用5.7版本,你要使用其他版本亦可。…

微服务巡礼 Spring Cloud 体系使用(一)Spring-Boot

微服务出现的时间并不长,是一个相对比较新的热点,这几年来有不少关于它的报道,本人以前也稍微听说过微服务,但并没有真正深入了解过相关概念,在工作中接触的机会并不多,平时学习也没有注意。正所谓百闻不如一见,公司最近引入微任务,一开始是打算使用Dubbo,经过权衡后打算使用Spring Cloud一站式全家桶应用减少学习和运维的成本,由于我们已经有一定Docker的使用积累,Spring Cloud推荐使用Docker部署的方式刚好切中我们的技术栈,我与Spring Cloud由此得以相识,并在使用中不断理解Spring Cloud和微服务概念。 相对来说,使用PHP的时间长过Java,由于天生的语言特性,配合Yii或者Laravel框架,接口开发速度比较可观,上线部署使用Docker和Walle都非常方便快速,业务快速迭代也能hold住,PHP 7自身性能也极为可观,因此都是以单体应用开发为主,一个单体应用提供总接口做成SOA服务,api端配合Swoole负责调用。回头想想这也是有微服务的影子,只是服务上的粗细度较为粗(事实上这个粗细度不好把握),业务的划分只是在内部逻辑上有明显区分,实际对外提供则是单一接口。 现在我们以微服务做比较,以前总服务接口中包含支付业务、普通业务、定时业务、活动业务等等各种各样的服务,包含在单一体系中,在长期业务迭代中,总体服务会变得越来越臃肿(所谓的技术债务,服务器的配置被迫越来越高)。达到一定程度后,在后面开发中会重构类似微服务的架构,将总服务拆分,支付业务成为一个SOA,…

最不喜欢的两个地方

我以前只不喜欢一个地方--医院,经历过亲人离去之后,有个更加不喜欢的地方--殡仪馆。 两者都给人一种非常压抑的感觉,医院救死扶伤的地方,普通病倒没什么大碍,重症病上躺着的病人,甚至是需要留医躺在床位上,都让人心头一紧。很少去医院这种地方,对医院的认识很多是从影视作品上了解,影视作品始终是影视作品,没有将现实中那种压抑的氛围拍出来。在我用一只手都可以数得过来的探院次数,每次都可以看到病人在与病魔战斗中,生态百样,脸上挤出的笑容多少包含无奈,让旁观者看到什么是活着就是一种罪。影视作品中表现出的积极向上的医疗态度?有是有,但也多局限在小病小痛,大病到来每个人都是平等的,抗风险手段多的话能稍微不那么担心,但也不可掉以轻心。 除了医院,现在第一让我不爽的地方是殡仪馆,从大门进去就能嗅到阎罗的味道,空气、景色隐约蒙胧一股冥界的气息,在传统观念上,不隔段时间做下法事都不安心。比起医院重症部摇摆不定的状态,这里的事实已经无法改变,来来去去的人一般沉默不语。不爽不是因为其天生,而是生命中重要的人离你而去,这里是他们最后一程,很多往事真的化成一道烟,随风而去。来这里一生都不会都有几次,可以肯定每次都承载很多过往的记忆,所有一切都只能追忆。 生命很脆弱,走过一趟殡仪馆的程序后,心中某些观念像断了的弦,掉落湖中泛起偏偏涟漪,被深深震撼。 世事无常,珍惜眼前人,别等走到最后的程序再来悔恨…

Vue略微接触

公司本身使用Vue,我本来比较倾向用React,两者各有千秋,精力有限的情况下,当然选择已经有实际项目运行参考,这些年的程序生涯让我明白到,技术只是手段,产出产品才是最重要的,讨论技术优劣上不必花费过多口水,因为两者都是非常优秀的框架,如何实现业务才是重中之重。 一、要解决什么业务场景 在三大前端框架诞生前,业界标准是Bootstrap + jQuery,最多加上一层less和sass,总体上属于html、css、js分层处理,在当时被誉为是优秀的设计。职责细分,分工明确,当时是业界标准。后来在前端不断发展下,维护的代价越来越高,界面元素越来越复杂,dom操作越来越多,css元素也跟着膨胀,虽然可以将css、js分割不同模块,但维护成本依然高昂,各种依赖越来越紧。为了解决这种业务导致的场景,三大框架横空出世,其中也涌现出其他非常优秀的框架,如avalon,但要说到广泛应用场景,还数Vue、React、Angular。 这三个框架网络上大把介绍,在我自己看来,最根本上解决的问题是,提供一套自动化工具和初始模板,将业务模块化,流程标准化,从真正意义上成为工程 二、使用过程,…

Webpack略微接触

Webpack作为JS打包工具,前端开发中必备,作用现在网上一大批说,这里没必要细说,稍微体验一下该工具的神器。 一、要解决什么业务场景 学习了解某个工具,一定是应对在实际应用场景中业务处理的难点而诞生。webpack最大的作用是1、减少HTTP请求,2、减少静态文件体积,3、模块处理机制,前端开发性能优化中,这两者无疑是最为重要的方面,因而webpack对应的作用就是在这两者中做工作,无疑的是,webpack没有局限这两个方面,在其他方面也有重要的发挥境地。 接下来体验一下。 二、使用过程,如何使用 http://webpack.github.io/ 1、起步 首先当然要看官网文档入步,2.x已经是webpack的终极版本(对于前端日新月异的情况实在是好事),可以直接从2.x入手。 2、安装命令 npm install webpack -g 全局安装,方便使用 3、开始使用 首先我们用了如图的文件结构,我们希望entry.js作为一个入口可以直接读取到其余的module文件,…

过度设计缓存的隐患

为什么要使用缓存?每当数据库的读取达到瓶颈,使用缓存是我们通常第一想法,缓存可以有效提高数据在高并发量下数据处理的能力。缓存这招大杀招虽然非常有效,但使用不好非常容易造成很多坑,反过来成为系统不稳定的根源,正常的数据库操作即使效率不高,但逻辑相对比较清晰,善用事务抛出问题也可以很快定位问题所在。也正因为如此,缓存更不应该被滥用,相反,我们应该在引进缓存之前,需要思考业务设计和系统本身的问题,先从业务上优化开始,思考系统设计的瓶颈,再在实际开发中遇到性能问题时适度使用缓存缓解。 下面分享一下使用缓存的习惯。 一、我们要解决什么问题 当访问数据的时候速度非常缓慢,需要解决这个瓶颈,更快返回数据。 二、解决方案的选择 数据库访问瓶颈我们第一时间想到一般是缓存,但不是所有数据都应该缓存,如缓存五分钟法则所讲:如果一个数据频繁被访问,那么就应该放内存中。缓存就是一种读写效率都非常高的存储方案,能够应对高并发的访问请求,通常情况下也不需要持久化的保证。但相对其他存储来说,缓存一般是基于内存的,成本比较昂贵,因此不能滥用。 缓存可以分为:本地缓存和分布式缓存。 1、本地缓存:主要指的是内存中的缓存机制。在PHP中,一般框架都会自己的缓存,Yii和Laravel都有一个类似的Cache的服务在其中,只需要在环境中配置就可以使用,在Java中,Google Guava中就提供了本地缓存的实现机制。…