前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >微服务:程序员和架构师的分水岭

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

作者头像
程序猿DD
发布2018-09-29 10:06:53
5730
发布2018-09-29 10:06:53
举报
文章被收录于专栏:程序猿DD程序猿DD程序猿DD

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

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

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

下面是他的自白书:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我是谁?

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

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

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

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

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

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

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

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-08-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 程序猿DD 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器镜像服务
容器镜像服务(Tencent Container Registry,TCR)为您提供安全独享、高性能的容器镜像托管分发服务。您可同时在全球多个地域创建独享实例,以实现容器镜像的就近拉取,降低拉取时间,节约带宽成本。TCR 提供细颗粒度的权限管理及访问控制,保障您的数据安全。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档