暂时未有相关云产品技术能力~
专注后端开发、架构相关知识分享,个人网站 https://howardliu.cn/。
我们的身体的精密程度远超机器可以比拟,大脑神经元复杂程度远远超过世界上任何已存在的机器,但是我们却没有最简单的机器那样精准计算和准确无误的存储。
《凤凰项目-一个IT运维的传奇故事》是一本比较神奇的书,用讲故事的方式,展现了IT团队(开发、测试、运维)在开发效能低、系统交付慢的情况下,通过实践三步工作法,在团队中实现加快系统交付、提升开发效能,使团队走上DevOps之路。
在 微服务的基建工作 中提到过,在云原生、微服务时代,如果还是手动修改服务地址,是几乎不可完成的工作,需要一种机制完成自动上报和获取服务地址的支撑组件,可以保障服务的快速上线和下线,这就是服务注册/发现组件。
前文说了一下《什么是微服务》,在文末提到,初创团队不建议直接使用微服务,对于初创团队,最根本的是活下去,而想要使用微服务,需要有很多基础建设。本文就来说下,微服务都需要哪些基础建设。
我所理解的微服务,就六个字:“高内聚,低耦合”。
我们都知道,程序猿是一种逻辑性极强的生物,他们不擅言辞,不擅表达,但是他们能够用一种神秘的语言与机器进行沟通,知道怎么让机器听他们的。
写这篇读后感的缘由是这本书的第三版即将面世了,先拜谢周教授,相信很多人得益于周教授的这本书。
目前很多互联网公司都采用微服务架构,微服务的优点和缺点被反复说到,这里不在重复赘述,只结合工作中的一些实践,说说要用微服务要注意的点,厚颜写做编程范式,其实就是一些具体实践而已。
现在手机越来越便宜,换手机是比较常见的一件事,所以各大厂商为了降低更换手机的成本,也是各种手段费尽心思:一键换机、云账号。。。但是这些方式都建立在一个基础上,就是同品牌手机才能用。如果是跨品牌换机,那真是要经历九九八十一难,百转千回才能顺利使用新机。像我这种懒人,可能还要在很长一段时间继续使用旧手机。
安装过程比较简单,就是下载源码包,下载依赖包,打包编译安装就完事了。
随着微服务架构的普及,线上服务越来越多,随之而来的就是部署越来越频繁;随着互联网行业的兴旺,产品迭代的频率也是越来越快,服务上线速度逐步提升。有上线、有部署,就有风险。有风险,就对业务有影响,然后就有了一系列减少这种风险的部署方案:蓝绿部署、金丝雀发布(灰度发布),也有适应产品迭代频率的AB测试。
最近这段时间在学习Spring Cloud,准备在项目中使用。Spring Cloud不能简单的算是一个框架,而应该认为是一个微服务的整体解决方案,它集成了Spring Boot、Netflix等等很多非常优秀的框架,很多组件开箱即用。也正是因为它集成了这么多框架,致使其版本不够稳定,即使是SR的版本,也存在这样那样的问题。甚至有的上一个版本没有问题,这个版本就出问题了。
前段时间对自己的项目进行代码质量扫描,曾经以为自己的代码质量算是不错的,结果发现一堆的bug或者smell code,灵魂受到1w点伤害。
java.lang.OutOfMemoryError这个错误是比较经典的错误了,经过JDK不断的迭代,服务器硬件的不断升级。。。总之,社会在发展,时代在进步。很多错误已经消失在时代的浪潮中。
最近在写一个应用监控的项目,使用netty作为数据传输。因为刚开始写,没有使用Protobuf之类的作为编码工具,只是使用的是netty自带的LengthFieldBasedFrameDecoder作为报文解析工具,自定义编码解码类,实现数据传输。
陆续的把Hadoop集群部署、HDFS的HA配置完成,把ResourceManager的HA配置好之后,Hadoop集群配置也算是完整了,可以满足小型中型生产环境Hadoop集群搭建的需要。如果真要搭建超大型的Hadoop集群,这些只能算是参考,还需要修改很多其他参数,使性能更好一些。
对Hadoop有过了解的都知道,Hadoop经历过很长一段时间的版本号混乱和架构调整,YARN是Hadoop 2.0(或者早期的0.23.x)提出的资源管理、任务调度框架。解决了很多Hadoop 1.0(或者0.21.x、0.22.x)时代的痛点。
如果对HDFS架构熟悉的话(如果不熟悉,可以通过HDFS架构了解),就应该知道,NameNode通过FsImage和EditLog两个文件管理DataNode的数据,Secondary NameNode会定期合并EditLog,以减少NameNode启动时的安全检查。
前段时间搭建了一套Hadoop集群的测试环境,因为服务器故障,废了。这几天闲来无事,想着把Storm用Yarn管理起来,于是再来一遍,同时也梳理下Hadoop组件中的一些概念。所谓书读百遍其义自见,不熟的系统多搭几遍,总会熟悉了,也就是所谓的刻意练习吧。
这几天压测预生产环境,发现 TPS 各种不稳。因为是重构的系统,据说原来的系统在高并发的时候一点问题没有,结果重构的系统被几十个并发压一下就各种不稳定。虽然测试的同事没有说啥,但自己感觉被啪啪的打脸。
在storm笔记:Trident应用中说了下Trident的使用,这里说下Trident几种状态的变化及其对应API的使用。
Java 坑如此大,需要慢慢填。 本文是列出JDK自带的一些工具,介于篇幅,简单列出工具列表及工具的作用。至少先做到知道有哪些工具,然后才能在实际中用到。
Trident是基于Storm的实时计算模型的高级抽象。它可以实现高吞吐(每秒数百万条消息)的有状态流处理和低延迟分布式查询。
作为中间件,消息队列是分布式应用间交换信息的重要组件。消息队列可驻留在内存或磁盘上,队列可以存储消息直到它们被应用程序读走。通过消息队列,应用程序可以在不知道彼此位置的情况下独立处理消息,或者在处理消息前不需要等待接收此消息。
一直听别人说 HTTP 长连接,只知道长连接比短连接更节省资源、更快捷,但是并不真的知道原因。知其然不知其所以然,对于技术来说,这种状态是比较危险的。所以,还是要挖一下原理,即使挖的比较浅,也要迈出这一步。
这是一个生产环境使用zookeeper异常的情况,错误是java.io.IOException: Packet len8854970 is out of range!。
在一些系统中,会有对某些任务状态进行跟踪,如果任务失败需要重新执行任务。本文主要是针对这种请求提出解决方案,因为时间原因,方案还没有在代码中实现。但是经过和 朋友 的推演,是目前能想到的比较有效的方案了。
这是一次比较苦逼的运维,完全不熟悉的系统、不清楚环境、不清楚配置,两眼一抹黑。为啥?就是因为原来的负责人撤了、交接人休假、再次交接人也休假,再再次交接人只有一份不全的文档。
笔记 - 颜色列表
用 Ubuntu 已经将近 1 年了,最近重装了 16.04 之后,每天到下午 5 点左右,都会发现 Swap 交换空间有几百兆的写入,系统内存 8G,硬盘是 SSD,i5 处理器,配置中档,也没有启动什么大型软件,就是用 IDEA 做开发,虽然没有影响,但本着一颗求知的心,google 一下,第一篇是 《All about Linux swap space》,口气很大,直接翻译了。
HTTP(Hyper Text Transfer Protocol)即超文本传输协议,采用请求/响应模型,是目前互联网使用最为广泛的一种网络协议。主要的过程:客户端向服务器发送一个请求,请求的请求头包含请求的方法、URI、协议版本、请求修饰符、客户信息、以及请求的内容等信息;服务器以一个状态行作为响应,包括消息协议的版本、成功或者错误编码、服务器信息、实体元信息以及实体内容。http 服务默认端口是 80,https 默认端口是 443。下图为 HTTP 服务简单的处理图。
伴随着各大互联网公司开源自己的大数据框架,大数据处理领域的框架已经比较完善。到现在所谓大数据的框架已经用过habase(后来换成了elasticsearch)、zookeeper、kafka、storm,根据项目计划,接下来还要使用spark。
Strom集群结构是有一个主节点(nimbus)和多个工作节点(supervisor)组成的主从结构,主节点通过配置静态指定(还有一种主从结构是在运行时动态选举,比如zookeeper)。通常这种主从结构存在出现单点故障的风险,Storm通过特殊处理规避这种风险,后面将解释Storm的半容错结构。
本文主要介绍storm中的基本概念,从基础上了解strom的体系结构,便于后续编程过程中作为基础指导。主要的概念包括
通过本文记录一下这种情况,后文中根据上述场景提供几个简单的例子。因为是初学storm、kafka,基础理论查看storm笔记:storm基本概念,,或查看Storm 简介。
众所周知,每一个HTTP响应都会带有一个HTTP状态码(HTTP Status Code),是用来表示HTTP服务器响应状态的代码。它由RFC 2616规范定义的,并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展。
DisMax扩展(eDisMax)查询解析器是DisMax查询解析器的升级版。除了支持所有DisMax查询解析器参数外,还扩展了DisMax
本文主要介绍下Solr解析器中通用的查询参数。这些参数能够在标准查询解析器、DisMax查询解析器及eDisMax查询解析器中通用。 下表总结了Solr通用的查询参数,支持标准的、DisMax、eDisMax查询请求。
DisMax查询解析器设计的初衷是处理用户输入的简单短语(没有复杂语法),在多个根据不同含义使用不同权重的字段间进行搜索。另外还有额外的选项,使用户可以根据具体用例(根据用户的输入)影响打分。
标准查询分析器的主要优势在于它支持强大且直观的语法,允许创建各种结构化的查询。与DisMax查询分析器相比,最大的缺点是它不能够容忍语法错误,而DisMax查询分析器比设计为尽可能少的返回错误。
在实际开发过程中,经常会需要定义一个文件,用于存储一些常量,这些常量设计为静态公共常量(使用 public static final 修饰)。这个时候就出现两种选择
古语云:人为财死鸟为食亡。司马迁也说过:天下熙熙,皆为利来;天下攘攘,皆为利往。人类发明这种货币方式,那它就可以从侧面衡量一个人的价值,甚至他对社会的影响力。简单的说,你的薪资反映了你对公司或对社会的价值,甚至你对人类发展的价值。本文主要说说钱,也就是薪资,程序猿、攻城狮的薪资。下面我要说的是普通人,那些太不普通的例子就不要用来反驳了。
场景 伴随着信息科技日新月异的发展,信息呈现出爆发式的膨胀,人们获取信息的途径也更加多样、更加便捷,同时对于信息的时效性要求也越来越高。举个搜索场景中的例子,当一个卖家发布了一条宝贝信息时,他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦,相反,如果这个宝贝要等到第二天或者更久才可以被搜出来,估计这个大哥就要骂娘了。再举一个推荐的例子,如果用户昨天在淘宝上买了一双袜子,今天想买一副泳镜去游泳,但是却发现系统在不遗余力地给他推荐袜子、鞋子,根本对他今天寻找泳镜的行为视而不见,估计这哥们心里就会想推荐你妹呀。其实稍微了解点背景知识的码农们都知道,这是因为后台系统做的是每天一次的全量处理
1 修改数据库字符编码 mysql> alter database mydb character set utf8 ;
awk是一个强大的文本分析工具,相对于grep的查找,sed的编辑,awk在其对数据分析并生成报告时,显得尤为强大。简单来说awk就是把文件逐行的读入,以空格为默认分隔符将每行切片,切开的部分再进行各种分析处理。
从别人的拿了一个EJB的demo,一个基础java工程作为工具jar包,三个ejb项目作为ejb基础库,一个web应用作为前端,另外加一个Enterprise Application Project作为统一的EAR项目。
在安装EOS Platform的时候,会有选择插件的界面,包括bps、cap、mobile(7.3提供)、sso。当选择的bps之后,在EOS的default包(应该称为基础包)中,将包含BPS的内容。EOS导出EAR包的原理是,将新建的EOS项目中的内容添加到default包中,然后将default整体导出为EAR包。在某些使用EOS项目中没有用到BPS,并且不需要BPS引擎启动,需要通过修改配置,禁用BPS服务。
内存溢出是软件开发过程中经常遇到的一些问题,在本地使用weblogic中间件的时候,可能会经常打包部署应用,重复多次之后,就可能出现内存溢出的情况。
EOS Platform支持标准的EAR,可以运行在weblogic服务器上,但是EOS Platform 7.2暂不支持weblogic12c,需要手动修改一些配置,然后才能够成功部署。
在实际工作中,需要用到EOS Platform,这是一个基于Eclipse的开发工具,自带了Tomcat,可以满足大部分需要,但是有时候需要使用Weblogic,这就得手动安装Weblogic插件了。这个过程与Eclipse相同(Eclipse下安装weblogic插件),本文中在EOS Platform 7.2中安装Weblogic插件。