为了账号安全,请及时绑定邮箱和手机立即绑定

众说纷纭微服务

2019.10.23 19:08 1649浏览

微服务是什么?杜克大学教授Dan Ariely说过一段非常出名的话,用来表述Big Data的发展现状。我觉得把这句话放到微服务身上也极其贴切。

Micro-services is like teenage sex:

Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it

微服务就像青春期性行为的话题,所有(小屁孩)都在讨论它,但没人知道怎么做,所有人都以为其他的人都在做,因此所有人都宣称他们自己也在这么做。

大到BAT级的应用,小到两三人的软件作坊,开发团队都会说自己的系统是使用“微服务架构”,这就像几年前大数据被吹到天上的时候,只要有一个数据库就可以说自己的系统是“基于大数据技术”。那这些所谓的微服务架构,到底是真微服务还是伪微服务?又或者是为了微服务而微服务呢?God knows

对我们来说微服务架构最直观的感受就是一个字“拆”,应用微服务化的第一步就是理清楚两个问题,“拆什么”和“怎么拆”。字面意思上很好理解,就是将一大坨纠缠在一起的服务拆分成单个服务,剥离出去。在这个阶段的课程当中我们从三个问题出发(What Why How),让大家对微服务架构有一个比较直观的理解

我们会从不同角度跟大家解释,什么样的服务才被称作是微服务,同时微服务架构对团队

1) 单一职责

软件工程的新理念层出不穷,但“单一职责”这句口号喊了几十年仍然是一条Golden Rule。如果说设计模式是“微观”领域的单一职责,那么微服务架构就是在“宏观”层面上做到单一职责。

单一职责不仅涉及到服务拆分,在微服务领域,这种职责划分要求将数据库、开发、测试、发布和运维都划归到一个领域模型里,由一个团队完全掌控应用的整个生命周期管理。对于庞大的应用系统来说,各个微服务模块可以用一种“小步快跑”的模式做迭代发布,提高了产品迭代速度

2) “微”团队

亚马逊的掌门人Jeff Bezos提出过一个很有意思的观点:The two pizza principle,双披萨原则。

Teams shouldn’t be larger than what two pizzas can feed

言下之意就是,如果两个Pizza还不能让你的团队吃饱,那么你的团队可能太大了。很可惜,它并没有说Pizza的大小,而且他的团队也没有老师这号凭一己之力就可以干掉2个Pizza的人。但是Jeff提出了一个蛮有建设性的意见,就是保持小规模的团队。

如果我们保持规模较小的特战队模式,那么这个团队的项目/模块规模必然也要控制在一定范围以内,他们所负责的项目也应当是一组相对较小,并且独立的功能单元。通常情况下并不是先有团队再有业务架构,实际上我们的团队应该是围绕“业务功能”来组织的。

3) 可独立部署

每一个微服务模块都应当是一个独立打包,独立部署的应用,在发布流程上与上下游应用没有直接的依赖,由开发团队直接负责线上发布操作。这种方式特别适合应用于微服务模块,保证快速迭代。

随着互联网行业的飞速发展,个人的衣食住行几乎全依赖各种APP来满足。每天早上起来刷刷淘宝,地铁上用视频app看个短句,一天微信不离手,睡前刷个抖音一不小心就刷到了后半夜,这些现象级全民应用层出不穷,所承接的用户访问量远飞上古时期的门户网站所能比拟的。在这种用户量级下还要能够满足不断变化的用户请求,就像给飞行中的飞机换引擎,传统的架构模式已经完全不能满足业务发展的节奏。

传统架构之殇

传统的单体应用+集群部署的机制,已经无法适应当今互联网行业的飞速迭代。一整个应用的代码掺杂在一块,代码东抄抄西抄抄,几年下去就堆成了一座“屎山”,随便一个小改动就牵一发而动全身,对底层组件的变更或升级更是如同噩梦一般的存在,更不用说那令人诟病的“瀑布模型”了,再小的变更,没有几个月的功夫都别想发布出去。

糙快猛是第一生产力

显而易见,传统架构的应用已经不能消化。为了贯彻互联网的糙快猛精神,我们必须从架构层面将内部服务解耦,拆解为一个个独立的服务模块,划分清晰的边界,已达到快速变更的目的。

How - 怎么拆分微服务

在这部分的内容中,我们将探讨微服务拆分的一般原则。俗话说最重要的一条原则就是“没有原则”,微服务既不是粒度越细越好(拆得跟马蜂窝一样),也不是越粗糙越好(否则直接搞单体应用了),我们的口号是“适合的才是最好的”。

比如对大型互联网公司来说,“大中台”就是一套构建在集团层次上的微服务治理理念。拿阿里来举例,集团各个事业部的业务模型最终都对接到所谓的“大中台”,从前端的商品服务、营销优惠服务、订单和用户服务,再到底端链路的支付结算和汇金平台等等,都有对应的中台业务方做支撑,在整个集团层面已经把中台业务做了细致拆分和领域划分,大大节省了新业务的接入成本。对中小型业务来说,拆分粒度不需要过细,识别出核心主链路,围绕主链路做拆分即可。

图片描述

我们初步计划将整个电商应用拆分为三个主要的微服务:商品服务,订单服务和用户服务。除了这三个主角以外,还有一些配角会陆续登场,比如提供用户鉴权的微服务等其他业务模块。

考虑到微服务架构有很多平台组件,比如注册中心、分布式配置中心、和各种监控组件,满打满算我们会有近二十个独立部署的应用,如果算上数据库和各类中间件,那么对电脑性能还是一个不小的挑战,8g或16g内存的电脑带这么多小弟还是蛮吃力的,所以建议同学们可以根据情况分模块启动项目。

国内外一线大厂技术大咖与慕课网组成专家团队12个月磨一剑

千万级电商项目从0到1到100全过程

涵盖Java程序员不同成长阶段的问题及最佳解决方案

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

3人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消