微服务的基建工作

前文说了一下《什么是微服务》,在文末提到,初创团队不建议直接使用微服务,对于初创团队,最根本的是活下去,而想要使用微服务,需要有很多基础建设。本文就来说下,微服务都需要哪些基础建设。

需要说明的是,下面这些组件,都是基于服务太多这个前提。

微服务的出现是为了研发效能的提升:相同的人数可以处理更多的需求、维护更多的产品,可以更快的交付产品。基于这点,微服务的基础组件,就从解放人力,减少人为失误出发。

下面给出一张微服务基础组件的图片:

微服务架构

更多

什么是微服务?

我所理解的微服务,就六个字:“高内聚,低耦合”。

没错,就是这个在软件开发过程中被反复提到的六个字,各类设计模式、架构设计、从入门到放弃等各种书中总会提到,从初级到高级到骨灰级程序员、架构师挂在嘴边的也是这六个字。只不过,在微服务概念之前,这六个字被用在类、模块、组件上,微服务则是将它放在服务上。

注:上面是精简版,下面是完整版,看官自便。

更多

微服务编程范式

目前很多互联网公司都采用微服务架构,微服务的优点和缺点被反复说到,这里不在重复赘述,只结合工作中的一些实践,说说要用微服务要注意的点,厚颜写做编程范式,其实就是一些具体实践而已。

更多

源码安装NGINX

本文主要记录一次从源码安装Nginx过程,参考的是Nginx官网

更多

瞎说八道之更换手机的成本

现在手机越来越便宜,换手机是比较常见的一件事,所以各大厂商为了降低更换手机的成本,也是各种手段费尽心思:一键换机、云账号。。。但是这些方式都建立在一个基础上,就是同品牌手机才能用。如果是跨品牌换机,那真是要经历九九八十一难,百转千回才能顺利使用新机。像我这种懒人,可能还要在很长一段时间继续使用旧手机。

更多

蓝绿部署、金丝雀发布(灰度发布)、AB测试

随着微服务架构的普及,线上服务越来越多,随之而来的就是部署越来越频繁;随着互联网行业的兴旺,产品迭代的频率也是越来越快,服务上线速度逐步提升。有上线、有部署,就有风险。有风险,就对业务有影响,然后就有了一系列减少这种风险的部署方案:蓝绿部署、金丝雀发布(灰度发布),也有适应产品迭代频率的AB测试。

本文主要是简单解释下这几个概念,帮助自己理解,如果有错误,请大佬们斧正。

更多

HTTP的响应头Vary

写在前面:Vary 是一个HTTP响应头部信息,它决定了对于未来的一个请求头,应该用一个缓存的回复(response)还是向源服务器请求一个新的回复。它被服务器用来表明在 content negotiation algorithm(内容协商算法)中选择一个资源代表的时候应该使用哪些头部信息(headers)。

更多

spring-cloud-config 非对称加密 keystore 文件加载异常

Spring Cloud Config是Spring Cloud一个全新的项目,依赖版本仓库(比如Git、SVN)实现分布式系统外部配置的集中管理。
文中Spring Cloud的版本是Dalston.SR4,可能在其他之后的版本有修改。

最近这段时间在学习Spring Cloud,准备在项目中使用。Spring Cloud不能简单的算是一个框架,而应该认为是一个微服务的整体解决方案,它集成了Spring Boot、Netflix等等很多非常优秀的框架,很多组件开箱即用。也正是因为它集成了这么多框架,致使其版本不够稳定,即使是SR的版本,也存在这样那样的问题。甚至有的上一个版本没有问题,这个版本就出问题了。

更多

代码质量管理:SonarQube + Jenkins Pipeline配置

前段时间对自己的项目进行代码质量扫描,曾经以为自己的代码质量算是不错的,结果发现一堆的bug或者smell code,灵魂受到1w点伤害。

可以想到,在时间紧、任务中的情况下,代码质量绝对是不能够保证的,虽然功能算是完整,但是可能就在某个隐藏的角落,就有无数的bug在潜伏着,所以有时间的话都对自己的代码进行代码质量检查吧。虽然不能保证有完美的代码,但是可以把bug数降低,也可以根据扫描的结果养成良好的编程习惯。

身为程序员就得严谨。

闲言碎语不再讲。

本文主要是介绍通过Jenkins Pipeline与SonarQube集成,对代码进行扫描,这里使用的是Jenkins2.19.1,SonarQube6.4。

更多

java.lang.OutOfMemoryError:GC overhead limit exceeded

java.lang.OutOfMemoryError这个错误是比较经典的错误了,经过JDK不断的迭代,服务器硬件的不断升级。。。总之,社会在发展,时代在进步。很多错误已经消失在时代的浪潮中。我也是很久没有见过这个错误了,以至于都以为在Java的世界中不会再碰到这个错误。结果,就在最疏忽的时候碰到了TA,真是,心中一万只神兽奔袭而过,狠狠的践踏了我这颗上了年纪的心脏啊。

吐槽完毕,言归正传。

Java刚刚出现的年代,有一个相比于其他语言的优势就是,内存回收机制。不需要明确的调用释放内存的API,java就自动完成,这个过程就是Garbage Collection,简称GC。这对以懒著称的程序猿们来说,绝对是重大利好。但是,凡事有利必有弊,可以肯定的是,Java语言是人创造的,GC也是人编写的代码,绝对不是机器自动完成的。也就是说,GC的过程是另外一群程序猿根据可能出现的情况,预设了GC条件,把符合回收条件的内存空间释放出来。一旦被占用的内存空间不符合释放的条件,GC没办法清理,那就会适时出现java.lang.OutOfMemoryError。这个错误就是提醒我们这群程序猿,写GC程序的程序猿不知道这种情况怎么处理,为了安全也不便处理,谁使用Java就自己看着解决吧。

说起来,java.lang.OutOfMemoryError有几种分类的,这次碰到的是java.lang.OutOfMemoryError: GC overhead limit exceeded,下面就来说说这种类型的内存溢出。

更多