Browsed by
分类:架构与架构师

为什么在做微服务设计的时候需要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 = Ser…

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的东西,并不复杂也并不长。你用别的s…

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