首页手记众说纷纭微服务

众说纷纭微服务

标签：

微服务

微服务是什么？杜克大学教授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），让大家对微服务架构有一个比较直观的理解

What - 什么是微服务

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

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) 可独立部署

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

Why - 为什么需要微服务

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

传统架构之殇

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

糙快猛是第一生产力

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

How - 怎么拆分微服务

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

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