微服务:程序员和架构师的分水岭

最近后台有不少朋友问到微服务落地的问题,今天给大家推荐一位朋友在这方面的心得。我先来介绍一下他。

胡忠想,微博昵称:古月中心相心,是技术领域近来蹿红的后起之秀,微博段子手,号称十万黑粉下江南的那种。不过人家正经职位是微博技术专家。2012 年加入微博,一直在做微博首页信息流相关的业务研发,你的微博被降权,估计就是他搞的。小胡几乎亲历了微博后端架构的每一次重大升级。不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造;还作为主要负责人之一,主导了微服务架构在公司多个业务线的推广和落地。

另外,胡忠想也是 Flag 先锋人士,2017 年初他刚刚改造完微博架构,立了个 Flag,说终于不怕明星出轨了,结果没多久鹿晗咔就恋爱了,于是微博挂掉半小时。忠想不服气啊,吭哧吭哧研发了好几个月核武器之后,他喘了口粗气在微博上说,现在可以支持八位明星并发出轨啦。终于微博不再挂了,毕竟八位明星出轨还是挺罕见的。古月因此载入微博史册。

下面是他的自白书:

近几年,微服务架构迅速在整个技术社区窜红,它被认为是 IT 软件架构的未来方向。我与同行交流时,提到微服务等新技术,他们先是兴奋,后又无奈。兴奋的是他们看到了新技术带来的便利,无奈的是团队规模和能力又反过来制约了他们采用新技术的步伐。这中间,我也发现大家对微服务有着不同的理解,但更多的是一些疑虑。不知道你是否也有这样的困惑,比如:

1、微服务这技术虽然面试的时候总有人提,但作为一个开发,是不是和我关系不大?那不都是架构师的事吗?

2、微服务不都是大厂在玩吗?我们这个业务体量用得着吗?

3、微服务特别复杂,没个100人的研发团队是不是就无法落地?

我特别理解这样的困惑。的确,大公司动辄就是几百上千的研发人员,并且其中不乏顶尖选手。他们有经验、有能力,也有业务场景,所以在技术的选择上也会更为冒进。而对于大部分的中小团队来说,当微服务架构成为刚需的时候,他们更多的是彷徨和犹豫。

那中小团队应该如何应用微服务呢?或者换句话说,中小团队的技术架构应该如何演进呢?

先给你讲讲我的经历吧。我2012年加入微博,最开始微博首页信息流的后端团队规模也不大,只有七八个人。当时我们就想着快速迭代,业务也就采用了单体应用的架构。因为求快,不同功能模块的代码耦合在一起,编译打包部署也都在一起。

后来业务规模不断扩大,团队人员也增长到二十多人,这时候单体应用架构的开发模式就开始暴露出问题了。那时候,每一次功能发布和上线都需要一个上线负责人来收集上线列表,并协调所有相关的开发人员合并代码到主干,然后编译打包,修改工程依赖的JAR包版本。

你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话,就会经常出现各种问题:有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认,耗费了大量精力,严重影响了整体的开发和部署效率。

看到这,不知你是否大腿一拍,大声叫到:这不就是我们团队每天都在面对的问题嘛!

是的,当时我们为了解决这些问题,做了很细致的技术调研,最后选定了服务化的解决方案。对原有的单体应用架构进行改造,把功能相对独立的模块拆分出去,部署为微服务,分别交给专门的更小的团队来维护。再到后来我们又引入了Docker容器化,以及Service Mesh等技术,为了更好地适应微博业务的高速发展。

可以说,微博的信息流后端架构经历了单体应用 -> 微服务架构 -> 容器化应用 -> DevOps的发展历程。而我也正是因为亲历了微博的架构演进过程,才对中小团队如何落地微服务体系有了更为深刻的理解。

在这个专栏里,我会秉承着“实用至上”的思路,不断提醒自己,这个方案中小团队是否可用,他们能否驾驭这些技术。我想,这是大部分中小团队的刚需,也是这个专栏的主要出发点。他们需要的不是一个大而全的东西,而是一套可以快速落地的方法论。

我希望在专栏里不仅跟你分享微服务架构的基础知识,更是从微服务体系的角度,和你深入讨论如何将微服务落地,帮你扫清最开始提到的那些疑惑。

我是谁?

我是胡忠想,微博技术专家。从2012年加入微博到现在,我一直在做微博首页信息流相关的业务研发,几乎亲历了微博后端架构的每一次重大升级。不仅参与了微博后端架构从大的单体应用迁移到微服务架构的改造;还作为主要负责人之一,主导了微服务架构在公司多个业务线的推广和落地。所以谈到将微服务落地,我有很多实战干货想和你分享。

在接下来的三个月里,我将由浅入深、由表及里,逐步带你探索微服务的世界,帮你从0开始构建微服务体系。具体来说,专栏分为四个部分:

第一部分,我会尽量用最通俗的语言讲解微服务架构的基本原理,帮你解答三个问题:什么是微服务?什么时候适合微服务改造?微服务架构到底是什么样的?

第二部分,我会结合在实际业务中的经验,给你讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案,以及搭建微服务架构时,如何做技术选型。

第三部分,我会给你讲述微服务、容器化、DevOps这三者之间的关系,以及在具体实践中如何运用这三种技术以给业务的架构带来质的飞跃。

第四部分,我会给你介绍下一代微服务体系可能的发展方向,并分享我对此的看法。

微服务是当下最火热的后端架构之一。不管你是一个什么级别的程序员,也不论你在一个什么体量的公司,服务化都是你迟早会遇到的难题。从我的经验来看,实践微服务的过程本身也是一个升级打怪的过程,这中间你会遇到基本上所有后端架构的问题。解决了这些问题,你自然也就理解了那些高深的概念,也就成为了一名架构师,成长和能力提升都是这个过程的附属品。

再或者,我也经常给刚毕业的同学开玩笑说,了解微服务架构之后,你起码能知道领导为啥叫你这么做,也更容易站在系统角度思考公司技术的进程,这对于你的大局观构建来说非常有帮助。

原文发布于微信公众号 - 程序猿DD(didispace)

原文发表时间:2018-08-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据观有话说

8项技能9种武器打造企业增长黑客(上)

自Facebook 2008年成立Growth Team伊始,“增长”已经成为企业公开追求的关键词。如何以最快的方法、最低的成本、最高效的手段谋得大量增长,成为...

1423
来自专栏Java架构

如何从三流程序员成长为一名年薪50W的架构师?1.源码分析专题2. 分布式专题3.微服务架构专题4.性能优化专题5.工程化专题6.电商项目实战

1883
来自专栏养码场

一个月面试 4 家,3 家Offer,面霸真君是这样面试的!

场主发现:有些技术人属于实战型,技术很6,但是不善于表现自我,于是面试倒成了offer的拦路石!不可不说可惜……

1184
来自专栏用户3246163的专栏

为什么DDD是设计微服务的最佳实践

在本人的前一篇文章《不要把微服务做成小单体》中,现在很多的微服务开发团队在设计和实现微服务的时候觉得只要把原来的单体拆小,就是微服务了。但是这不一定是正确的微服...

1442
来自专栏腾讯大讲堂的专栏

鹅厂交互设计师如何写交互文案

做交互的时间越久,越发现文案的重要性;今天我们来聊聊交互文案。 ? ---- 文案最初是桌子的指代,后来演变成一种职业;现在说起文案一般指以文字表现创意策略。交...

23710
来自专栏罗超频道

微信公众账号公开阅读数和支持点赞,微博化开始

腾讯微博“倒掉”腾讯要扶微视上位?No,还有微信呢! 如果你细心,会发现一些微信公众账号推送的图文消息页已经有一个小的改版:作者信息不在于日期和公众账号信息...

3585
来自专栏数据观有话说

8项技能9种武器 打造企业增长黑客(上)

自Facebook 2008年成立Growth Team伊始,“增长”已经成为企业公开追求的关键词。如何以最快的方法、最低的成本、最高效的手段谋得大量增...

1452
来自专栏Java架构师进阶

真正的程序员都是在拼命往前走的

  对于软件这一行的人,我们有个很大的挑战,就是如何能够用正确方法的做事情。什么是正确的方法,这依赖于你在做什么和做给谁。而究竟所谓 “正确的方法”里都包括了什...

822
来自专栏java工会

什么是架构师?

  很多的创业公司,一人身兼数职的情形还是很常见的。至少,我是经历过的,一个人包办了所有的开发过程,连测试我都做了,绝对的一条龙,但是经常踩钢丝、骑独轮车总会有...

1501
来自专栏大数据文摘

InfoQ采访PWorld2015讲师:解读“微服务”架构

2186

扫码关注云+社区

领取腾讯云代金券