Browsed by
分类: 并发与分布式

我是如何一步一步监控公司MySQL的每一个操作?

我是如何一步一步监控公司MySQL的每一个操作?

閱讀本文約花費: 11 (分鐘)作为一个程序员,闲下来还是喜欢学习钻研一些新奇的技术,canal就成了很好的研究对象,一不小心就监控了公司MySQL的一举一动的 一、canal是个啥? canal是阿里开发的一款基于数据库增量日志解析,提供增量数据订阅与消费的框架,整个框架纯JAVA开发,目前仅支持Mysql和MariaDB(和mysql类似)。 那什么是数据库增量日志? MySQL的日志种类是比较多的,主要包含:错误日志、查询日志、慢查询日志、事务日志、二进制日志。而MySQL数据库所发生的数据变更(DML(data manipulation language)数据操纵语言,也就是我们熟悉的增删改),都会以二进制日志(binary log)形式存储。 二、canal原理 在介绍canal原理之前,我们先来回顾一下MySQL主从同步的原理,这或许会让你更好的理解canal的工作机制。 1、MySQL主从同步原理: MySQL主从同步也叫读写分离,可以提升数据库的负载和容错能力,实现数据库的高可用 先来分析一张MySQL主从同步原理图: image 以上图片源自网络,如有侵权联系删除 master节点操作过程: 当master节点数据发生更改后(delete、update、insert,还是创建函数、存储过程等操作),向binary log中写入记录日志,这些记录又叫做二进制日志事件…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

为什么在做微服务设计的时候需要DDD?

为什么在做微服务设计的时候需要DDD?

閱讀本文約花費: 9 (分鐘)记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢?』 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性。但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可。 回到主题,我们要了解的是微服务和DDD到底有什么关系呢? 因为在互联网时代,软件所面临的问题域比以往要复杂得多,这种复杂性来源于不断扩展的问题域自身,也来源于创新变化,以及这种规模性增长所带来的挑战。 然而一个人一个团队,他对复杂的事物的认知是有极限的,面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分;治意味着分出来的每一个部分要能够独立的运行,能够互相的协作,完成整体的目标,能够一来应对外部变化所带来的冲击。 微服务的缺陷 微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践,那微服务是不是解决复杂问题的银弹呢?其实不然,很多团队在应用了微服务架构来构建他们的系统以后,发现并没有完全解决这种复杂性问题,甚至还带来了一些其他的问题。比如: 服务并没有解决复杂系统如何应对需求变化这个问题,甚至还加剧了这个问题…

Read More Read More

微服务划分的姿势

微服务划分的姿势

閱讀本文約花費: 10 (分鐘)我们知道微服务是一种理念,没有确切的定义和边界,好比设计原则,是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话,具体问题需要具体分析,所以这篇文章谈到的划分也不是绝对标准,仅供参考。 有人说微服务不难,难的是服务的划分,虽然我持保留意见,但是从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度,如果粒度太大了,分和不分似乎都差不多;如果粒度太小了,聚合、发布、调用链、调试等都是坑。 以下谈到的拆分是前人经验的总结,我罗列了三种行家的拆分姿势,每个的的经验和视野不同,各有偏颇,我在这里更多的是谈共鸣和感受,希望对你有所启发。 拆分姿势 姿势一:新浪微博微服务专家胡忠想从纵横两个维度来划分,简单粗暴。 纵向拆分 从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务。 横向拆分 从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。 纵向以业务为基准,关系铁的在一起;横向功能独立的在一起。我想如果拆分这么简单,你有底气拆,敢拆吗?所以我们又继续比对一下其他专家的言论。 姿势二:阿里的小伙伴从综合的维度来看,部分维度和上面会有重合 服务拆分要迎合业务的需要 充分考虑业务独立性和专业性,避免以团队来定义服务边界,从…

Read More Read More

Java微服务实践乱谈

Java微服务实践乱谈

閱讀本文約花費: 25 (分鐘)楔子 目前业界最流行的微服务架构正在或者已被各种规模的互联网公司广泛接受和认可,业已成为互联网开发人员必备技术。无论是互联网、云计算还是大数据,Java平台已成为全栈的生态体系,其重要性几乎不可替代。 这两年微服务作为一个非常新的技术,各种理论流派试图从不同的角度去阐述其概念和优势,我一开始是拒绝的,因为我没有”Duang“的一下想清楚。个人感性地认知是,姿势不对,纯靠意会。理性的看法则是,在思想上,那些布道师们并未达到一致。经过参考各家思想之后,得到了一些自己的领悟,我分享给大家。 微服务是什么? 微服务是一种细粒度(Fine-Grain)的SOA 个人认为,与其说微服务是一种技术,不如将其定义为一种架构,而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景,进行合理地划分业务边界,实现“业以类聚”,然而“技”的实现则通过特定的技术在实现业务逻辑之时,更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性,达到“技以群分”的目的。 由此而论,我个人偏好将其定义为:“微服务是一种细粒度的SOA”。 这样定义的好处在于,没必要去重复地“抹黑”“单体应用”(Monolithic,也有人翻译成“巨石应用”),缘于SOA技术的衍化过程中早已提及。那么,细粒度更多的体现在“取其精华,去其糟粕”。 SOA又是什么? SOA = Serv…

Read More Read More

《microservice & serverless》的一点感想

《microservice & serverless》的一点感想

閱讀本文約花費: 6 (分鐘)超哥是来自Amazon的顶级的架构师,经历了Amazon整个向微服务架构迁移的过程,以及向serverless的演化过程,有着极其丰富的经验,年过40,一直站在技术的最前沿,始终保持对技术的执着追求和热情,是名副其实的技术大牛,能与之一起工作,荣幸之至!今天超哥给我们分享的主题《microservice & serverless》,是超哥实际工作经验的一些分享,也为公司架构的演化提供了新的思路和指导。 microservice(微服务)这个可能是这些年最火的一种架构设计了,频繁地出现在各种技术大会上,各大互联网巨头纷纷向这种架构演化,很多小的互联网公司也往这些概念上去靠,大有一种不做微服务就要落伍的趋势。事实上,很多对于微服务的理解比较粗浅,盲目的微服务化甚至会带来更多的负面影响。 目前Amazon内部运行着超过2w过微服务,但是这些微服务并不是凭空产生的,在这之前,运行的服务都是超大的单体服务,但是随着业务的发展,这种服务在整个研发的pipeline(设计→研发→编译→测试→发布→部署→运维)中都出现了一些问题。设计阶段,老的单体服务会给我们带来一些技术限制,比如有些技术只有python语言的实现,但是我们的服务使用java开发,这样我们不得不拿出一个更复杂的设计去解决类似的问题;研发阶段,随着开发人数越来越多,代码冲突的问题越来越多,我们不…

Read More Read More

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

面试官:你知道java类是怎么跑起来的吗?问的我一脸懵

閱讀本文約花費: 15 (分鐘)类从加载虚拟机内存中开始到卸载出内存为止,生命周期包括:加载、验证、准备、解析、初始化、使用、卸载。 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须按照这种顺序进行,而解析阶段则不一定,它在某些情况下可能在初始化阶段后在开始,因为java支持运行时绑定。 加载阶段 通过一个类的全限定名来获取定义此类的二进制字节流(没有指明二进制字节流要从一个Class文件中获取,可以从ZIP包中读取,从网络中获取,运行时计算生成等等) 然后,将这个字节流所代表的静态储存结构转化为方法区的运行时数据结构在内存中生成一个代表这个类的java.lang.Class对象,也就是说,当程序中使用任何类时,系统都会为之建立一个java.lang.Class对象。 该Class对象作为方法区这个类的各种数据的访问入口完成后,虚拟机外部的二进制字节流就按照虚拟机所需格式储存在方法区中。 这里稍微理解一下对象和类的概念,对象是实例化的类。类的信息是存储在方法区中的,对象是存储在Java堆中的。类是对象的模板,对象是类的实例。 类的加载由类加载器完成,类加载器通常由JVM提供,这些类加载器也是前面所有程序运行的基础,JVM提供的这些类加载器通常被称为系统类加载器。除此之外,开发者可以通过继承ClassLoader基类来创建自己的类加载器。 其实加载阶段用一句话…

Read More Read More

戴森印象记

戴森印象记

閱讀本文約花費: 36 (分鐘)2020 年 2 月 28 日, 著名物理学家弗里曼·戴森 (Freeman Dyson) 在美国去世, 享年 96 岁。 戴森去世的次日早晨, 我收到《上海书评》编辑的微信, 约写一篇关于戴森的文章。 我说我只能写一篇不全面, 且并非一味 “点赞” 的文章。 诸位现在读到的就是这篇文章。 这篇文章之所以不全面, 是因为戴森太全面了——他的兴趣涉及了太多领域, 我不仅没有时间追随, 很多领域甚至没有兴趣追随, 因此注定不能全面。 至于并非一味 “点赞”, 大家读下去就清楚了。 虽然文章不全面, 我书架上和电脑里的戴森著作倒是比较全面的, 只可惜聚书快而读书慢, 已读过的只占一小部分。 除戴森本人的著作外, 我还读过美国作者 P. F. 舍维 (P. F. Schewe) 撰写的戴森传记《Maverick Genius》 (特立独行的天才) 的若干章节。 这篇文章本质上是那些阅读的随感, 也是阅读所得的戴森印象, 故曰 “印象记”。 最早读戴森是在二十多年前。 当时我在复旦, 不久将要赴美, 最后几个月闲来无事, 便从图书馆找了些闲书看, 戴森的《宇宙波澜》也在其列。 后来回想起来, 当时读那本书印象最深的细节是: 一位学生通过公开可查的资料, 汇集了制造原子弹的步骤, 精确得让戴森大吃一惊, 在给了学生 “A” (“优”) 之后, 嘱咐其烧掉文章。 …

Read More Read More

Coolshell:应该知道的Linux技巧

Coolshell:应该知道的Linux技巧

閱讀本文約花費: 14 (分鐘)这篇文章来源于Quroa的一个问答《What are some time-saving tips that every Linux user should know?》—— Linux用户有哪些应该知道的提高效率的技巧。我觉得挺好的,总结得比较好,把其转过来,并加了一些自己的理解。 首先,我想告诉大家,在Unix/Linux下,最有效率技巧的不是操作图形界面,而是命令行操作,因为命令行意味着自动化。如果你看过《你可能不知道的Shell》以及《28个Unix/Linux的命令行神器》你就会知道Linux有多强大,这个强大完全来自于命令行,于是,就算你不知道怎么去做一个环保主义的程序员,至少他们可以让你少熬点夜,从而有利于你的身体健康和性生活。下面是一个有点长的列表,正如作者所说,你并不需要知道所有的这些东西,但是如果你还在很沉重地在使用Linux的话,这些东西都值得你看一看。 (注:如果你想知道下面涉及到的命令的更多的用法,你一定要man一点。对于一些命令,你可以需要先yum或apt-get来安装一下,如果有什么问题,别忘了Google。如果你要Baidu的话,我仅代表这个地球上所有的生物包括微生物甚至细菌病毒和小强BS你到宇宙毁灭) 基础 学习 Bash 。你可以man bash来看看bash的东西,并不复杂也并不长。你用别的sh…

Read More Read More

《REWORK》摘录及感想

《REWORK》摘录及感想

閱讀本文約花費: 45 (分鐘) 读了《Rework》这本书好多遍,每次读都有不同的感想。但从来没有把这些感想记录下来,今天把《Rework》书中的一些章节做一些摘录,并把我的一些感想总结出来。供大家参考。这是一本平生以来让我中毒很深的书,也是一本让我思考得很多的书。希望看到这篇文章的人都能好好地读读这本书。这本书并不难读,是一本你可以一口气不中断就可以读完的书。 现实世界 “这在现实世界里面行不通”,当你向人们介绍一个新创意时,人们总是这么回答你。这个“现实世界”听起来如此令人沮丧,……只有人耳熟能详,习以为常的事情才会胜利,即使是这些事情已经漏洞百出陈腐低效。 揭开“现实世界”这个锅盖,你会发现居住在里的人都充斥着悲观主义和失望的情绪。更糟的是,他们想将别人拖进他们的坟墓。如果你是充满希望和野心的人,他们会试着说服你,你的想法是不可能的。他们会说你在浪费时间。 “现实世界”并不存在,那只是人的一个借口。只是某些人为了开脱 自己的无所作为,跟你一点关系也没有。 感想:我经常会向一同事和朋友提及一些我的想法,朋友同事们经常会回答我——这个事某某人,某某团队做过了,没成功。或是对我说,你做这个事的时候,要小心这个要小心那个。我觉得,这个时候是最考验我们的时候了,要有一个清醒的头脑去分析别人的话,别人真不代表自己。这个世界上大多数人都是比较保守的,大多数都对这个现实世界都有或多或少的恐…

Read More Read More

5分钟,告诉你Mysql字符串怎么做索引

5分钟,告诉你Mysql字符串怎么做索引

閱讀本文約花費: 4 (分鐘)很多程序员都不喜欢字符串,我也是,字符串处理起来太麻烦了,而且字符串也比较占空间。举个例子,一个字符要占1个字节,但一般常用字符就那么几个(例如我们常要求用户名只能是大小写字母与数字)。另外一个问题,就是数据库查询的时候,用字符串查询太不方便了。今天我们来了解下,数据库中的字符串查询问题。 在PC互联网时代,我们的很多账户都需要绑定电子邮箱,我们偶尔需要使用电子邮箱,也就是字符串来进行数据查询,为了保证查询效率,我们通常要对字符串字段建立索引。 我们都知道,在InnoDB中,通常使用的是B+树索引,如果索引的类型是字符串,那么我们可能会面临这样一个问题,索引的长度会变得特别长,索引的长度过长会让索引的索引占用更多的存储空间,同时也会增加索引的维护成本。通常我们使用字符串索引,只会使用前面若干个字符,假如用户的邮箱的开头是26个字母,并且用户名随机均匀分布的,那么我们即使使用第一个字符做索引,也能减少25/26的扫描量,假如使用前2个字符,就可以减少675/676次扫描。所以,即便我们只用前面的若干个字符,也能大大地减少数据库的扫描,提升查询速度。 但是在现实生活中,用户名往往不是随机分布的,像a开头的用户往往占比较大。有些字符串的字段,往往开头是相似的,例如居民的身份证好,前面几位数通常是省份跟城镇,教育局的学生信息,通常id是入学时间加月份,索引的选…

Read More Read More

软件架构设计-五视图方法论(2)

软件架构设计-五视图方法论(2)

閱讀本文約花費: 8 (分鐘)1.每个人都可以做成为架构设计师 不懂软件的和刚入行的人们一听到架构设计,都认为是非常的高大上课题,是一个遥不可及的领域,一般人是不能做的。听起来云里雾里的,第一印象除了来自微软,阿里这些NB的公司里面的人其余的都不能做出架构似的,这是一种先入为主的思想,因为大家都在强调架构师的重要性,他的薪资有多么的高,在整个社会对他的认定导致很多人对架构设计望而生畏。放正自己的心态其实架构设计并没有多么的复杂。我们是从编码入行的,在编码实现功能的过程中我们或多或少的设计了属于自己的软件架构了。 为什么说软件架构师需要多少年的工作经验,因为软件架构就是系统的草图,不仅是代 码编写而且包括部署,运行、开发等这些方面进行设计,目的是为了保证软件开发、运行、扩展、性能、安全、伸缩等等质量的一个保证。只要在编码过程中不仅仅要提升编码的质量而且要留心其他方面的知识积累与学习,用不了多久你也能成为一位优秀的架构设计师。 2.什么是架构设计 我们要成为架构设计师我们需要了解什么是架构设计。简单一点,架构设计就是一个系统的草图,描述了构成系统的抽象组件,以及各个组件之间的是如何进行通讯的,这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中,组件之间的联通通常面向于接口实现的。 在“软件架构简介”中David Garlan 和Mary Shaw 认为软件架构师…

Read More Read More

Kubernetes HPA 详解

Kubernetes HPA 详解

閱讀本文約花費: 32 (分鐘)Kubernetes HPA 详解 在前面的学习中我们使用用一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要应对线上的各种复杂情况,我们需要能够做到自动化去感知业务,来自动进行扩缩容。为此,Kubernetes 也为我们提供了这样的一个资源对象:HorizontalPodAutoscaling(Pod水平自动伸缩),简称 HPA,HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量,这是 HPA 最基本的原理: 我们可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象, HPAController默认 30s轮询一次(可通过 kube-controller-manager 的 –horizontal-pod-autoscaler-sync-period 参数进行设置),查询指定的资源中的 Pod 资源使用率,并且与创建时设定的值和指标做对比,从而实现自动伸缩的功能。 Metrics Server 在 HPA 的第一个版本中,我们需要 Heapster 提供 CPU 和内存指标,在 HPA v2 过后就需要安装 Metrcis Server 了, MetricsServer 可以通过标准的 Kubernetes A…

Read More Read More

软件架构设计-五视图方法论

软件架构设计-五视图方法论

閱讀本文約花費: 12 (分鐘)在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的 ​​​在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了对架构的一些理解,希望能够补充很多初入门的人在这方面认识上的不足,纠正一些误解。高手和老鸟就直接跳过吧。 架构的分类 对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。 逻辑架构:逻辑架构关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。 开发架构:开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。 运…

Read More Read More

Spring源码笔记之Bean加载之准备创建Bean

Spring源码笔记之Bean加载之准备创建Bean

閱讀本文約花費: 16 (分鐘)我们知道从spring容器中获取单例bean时会先从缓存尝试获取,如果缓存中不存在已经加载的单例bean就需要从头开始bean的创建,而bean的创建过程是非常复杂的,本文就开始研究bean加载这部分的源码。 1. bean创建流程分析   在Spring中bean加载的逻辑是在getSingleton的重载方法中实现的: public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) { Assert.notNull(beanName, “‘beanName’ must not be null”); // 全局变量需要同步 synchronized (this.singletonObjects) { // 首先检查对应的bean是否已经加载过,因为singleton模式就是复用已创建的bean,所以这一步是必须的 Object singletonObject = this.singletonObjects.get(beanName); // 如果为空才可以进行singleton的bean的初始化 if (singletonObject == null) { if (this.singletonsCurrentlyInDestruction) {…

Read More Read More

Scroll Up