![](https://img-blog.csdnimg.cn/20201014180756738.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
微服务
文章平均质量分 60
四猿外
微信公众号@四猿外。
你好,我是四猿外。
一家上市公司的技术总监,管理的技术团队一百余人。
我从一名非计算机专业的毕业生,转行到程序员,一路打拼,一路成长。
我会把自己的成长故事写成文章,把枯燥的技术文章写成故事。
展开
-
引入微服务带来的一些问题
微服务的引入还有各种各样的问题,包括:1.额外引入的复杂性微服务会带来各种各样的成本的提升,也会引入各种各样的技术问题。这些最终就会导致整体系统复杂性进一步的提高。当复杂性提高的时候,为了保证系统的稳定,就需要整体技术团队的靠谱,就需要技术人员的靠谱,就需要整体技术设施搭建的靠谱。在引入微服务之前,各位兄台麻烦扪心自问下,这些贵公司有吗?有这些团队、这些设施、这些资源吗?2.分布式本身带来的成本分布式本身就需要一整套完整的技术体系和设施去支撑整体分布式的建设。比如,以前单体项目只需要一个项目,直接人原创 2021-06-04 13:49:57 · 511 阅读 · 3 评论 -
危险!水很深,让叔来 —— 谈谈命令查询权责分离模式(CQRS)
多年以前,那时我正年轻,做技术如鱼得水,甚至一度希望自己能当一辈子的一线程序员。但是我又有两个小愿望想要达成:一个是想多挣点钱;另一个就是对项目的技术栈和架构选型能多有点主动权。多挣点钱是因为当时我刚结婚不久,有自己的家庭规划,所以挣钱的欲望也蛮强。而想有多点技术主动权的原因则是当时领导很赏识我,有些东西逐渐的放权让我做,我尝到了甜头,所以,也有了自己的一些小野心。而正巧就在那时候,领导给我了一个现在看来职业生涯中还挺重要的机会。当时,广告联盟正是发展的如火如荼的时候,公司也想参与进去分杯羹,于是原创 2021-06-03 15:07:53 · 461 阅读 · 8 评论 -
拯救祭天的程序员——事件溯源模式
一、事前你相信吗?曾经有一段日子,我几乎没接到过合格的产品需求。开局几句话,技术全靠猜。总是以为简单的需求曾经,我从产品那里接到过这么一个需求:对系统的用户进行分级,不同级别的用户有不同的福利。依然如常,无图无文档,只是这么一句话。我知道,需求一句话,分析五日功嘛。为了项目能持续发展,我只好自己分析自己搞了。从业务上看,目前的用户对象尚无等级一说,我们先为用户对象加上个级别属性。又因为不同的用户等级,可享受到不同的福利。比如:达到 3 级的用户,可以享受购物 9.5 折优惠,物流费用全免,原创 2021-05-31 17:25:29 · 508 阅读 · 0 评论 -
当年一穷二白搞微服务的日子……我太难了
在我最初接触微服务的很长一段时间里,有两类问题都困扰着我和团队,这是让我印象最深的两类问题:没有配合微服务理念的团队没有配合微服务理念的基础设施后来,在和一些搞了微服务的同行多次交流后,发现他们当初也面临和我类似的问题。这次就写写我最早搞微服务遇到的问题。有些问题放到现在来说,已经有解决办法了,已经算不上问题了。但是无论怎样,这些问题如果能提前意识到,早做准备,会为将来搞微服务的同仁们省下许多的力气。所以,这篇文章我会着重谈下这两类问题。一、没有配合微服务理念的团队当年,我还是一个小开发原创 2021-05-17 13:22:51 · 2235 阅读 · 2 评论 -
恕我直言,微服务挺好,但你不配
今天这篇文章我们继续说架构师大刘的故事。故事纯属虚构,别对号入座哈。前言大刘日子最近还不错,经常午睡醒来,就继续拿着手机看小说摸鱼。大刘对当前所在的这家公司比较满意。大部分系统已经成熟稳定,用户量也中规中矩。虽然有些项目技术陈旧,但好处是没啥幺蛾子技术问题冒出来等着解决。只是有时候大刘心里会打鼓,公司盈利在下降,巅峰不在,也不知道这家公司能撑多久。除了偶然会冒出些对工作稳定的担忧以外,大部分时候,大刘心情都是愉快的。直到他被领导叫到办公室分派新任务的那一刻……大刘的领导 CTO 老李,这原创 2021-05-08 16:59:08 · 264 阅读 · 2 评论 -
“一学就会,一做就废”——微服务的架构模式:一个服务一个数据库模式(中)
今天这篇文章我想谈谈:一个服务一个数据库这种最基本的模式落地,大体的做法是怎么样的。一、搞微服务,可能是个政治问题我第一次接触微服务的时候,真的是迫不得已。公司有一套大型系统,这套大型系统当时是负责公司的主要盈利业务,非常非常重要。但是,正因为重要,所以它就成为了产品、业务团队的重点服务对象。这些人天天想着把这套系统的业务做出花来,不断对技术团队提出各种各样的需求。提出需求不说,还要求技术能快速迭代。一旦不能及时上线他们的需求,产品经理们就会在各种会议上抱怨,说技术团队影响了速度,出现了原创 2021-05-08 16:47:45 · 462 阅读 · 0 评论 -
“一学就会,一做就废”——微服务的架构模式:一个服务一个数据库模式(上)
不管你喜不喜欢微服务,现在微服务无疑已经是程序员们绕不过去的话题了。无论你是想把目前的架构改成微服务,还是你要出去面试高级一点的岗位,需要深入理解微服务。提起微服务,很多程序员对它是又爱又恨,想学微服务不知道如何开始,学了一点之后,又找不到地方去实践。总之就是感觉微服务遥不可及,又很难驾驭。首先要明白的是微服务是有套路的,而这些套路基本上解决了微服务结构面临的几乎所有重要问题。这些套路就是微服务自己的架构模式如果我们能深入了解这些模式的其来龙去脉,就可以理解了微服务绝大部分内容。学习快速,实原创 2021-04-30 14:42:50 · 192 阅读 · 0 评论 -
微服务落地—第三步:对方法进行分类
第三步:对方法进行分类把梳理出来的所有方法做一次分类,分成两类:功能模块直接对外部用户的方法,功能模块内部之间需要调用的方法。原创 2021-04-29 15:43:55 · 118 阅读 · 0 评论 -
微服务落地—第二步:梳理功能模块的方法
第二步:梳理功能模块的方法搞清楚业务模块了还不够,你还需要搞成分开的服务,所以,必定需要把服务之间的联系也给确定好。这时候,如果是从零开始就很好搞了,自己根据业务划分的情况,直接自行创建对应的方法就好。如果针对已有项目拆分,那就不好搞了。非得仔细梳理源码,然后根据源码的类和方法,逐次清理出各个模块的之间的方法调用。非常麻烦。...原创 2021-04-29 15:43:00 · 320 阅读 · 0 评论 -
我第一次搞微服务——在祖传项目上摸石头过河
我当时第一次搞微服务的事情。由于迁移微服务不是一蹴而就的事情,但是我又急需一些微服务的部署简单、开发快速的优点。所以,当时不得已,想了个折中的办法。我把一些急需实现的业务需求分析了下,发现这些需求大体可以分为以下两类: 有些需求本身是一套独立的边缘业务 有些需求是集中在核心业务的边缘上 我后来想想,觉得这是理所应当的。业务和我们技术一样,如果动了核心业务的逻辑,万一出现了问题,他们是要背大责任的。但是他们又要体现自己的价值,那最保险的就是在核心业务的边边角角动些手脚。知道了这原创 2021-04-29 15:38:22 · 107 阅读 · 0 评论 -
什么时候考虑用微服务
从我接触微服务以来,迄今也得有五六年了。断断续续要么从零开始,要么中途接手,也经历了 5 套微服务项目了。从这些项目中的经验以及和同行交流来看,根据业务切分微服务的方法总的来说思路不复杂,但是落地总是出现了各种各样的问题。一直到现在,我也还在探索着最好的微服务落地的最佳办法。我后续接触的微服务越来越多了,为了用好微服务,我真的是狠狠钻研了下微服务这套体系架构,也总结了一些自己对微服务分解实践的经验。 首先,如果是预估到业务在飞速增长,那就别犹豫,一定要提前考虑微服务的拆分。 其次,如原创 2021-04-28 12:56:34 · 1156 阅读 · 1 评论 -
搞微服务,有时候是个政治问题
我第一次接触微服务的时候,真的是迫不得已。公司有一套大型系统,这套大型系统当时是负责公司的主要盈利业务,非常非常重要。但是,正因为重要,所以它就成为了产品、业务团队的重点服务对象。这些人天天想着把这套系统的业务做出花来,不断对技术团队提出各种各样的需求。提出需求不说,还要求技术能快速迭代。一旦不能及时上线他们的需求,产品经理们就会在各种会议上抱怨,说技术团队影响了速度,出现了让竞争对手迎头赶上的风险。技术团队有口难言,因为系统太庞大了,改动那么大的系统真的很困难。至于原因,我也在上篇文章说了,不原创 2021-04-28 12:43:21 · 140 阅读 · 0 评论 -
微服务的架构模式之:一个服务一个数据库
微服务最基本的模式就是:一个服务一个数据库上图就是一个最简单的微服务模式了。一个服务一个数据库这种模式,是微服务体系结构中的最基础也是最核心的模式。看着简单,但是,这个模式蕴含着微服务的最基本的思想。...原创 2021-04-13 20:32:26 · 522 阅读 · 0 评论