为什么要微服务（服务化）？

“微服务架构”的话题非常之火，很多朋友都在小窗我，说怎么做服务化？解答“怎么做”之前，先得了解“为什么做”。

画外音：做技术千万不能是这种思路，“别人都在做，所以我们也要搞”。

并不是所有的业务都适合“服务化”，互联网高可用架构，到底为什么要服务化？

服务化之前，高可用架构是什么样的？

在服务化之前，互联网的典型高可用架构如下：

（1）客户端，APP，H5，小程序，PC浏览器；

（2）后端入口，高可用的反向代理nginx集群；

（3）站点应用，高可用的web-server集群；

（4）后端存储，高可用db集群；

更典型的，web-server集群通过DAO/ORM等技术来访问数据库。

可以看到，最初是没有服务层的，此时架构会碰到什么典型痛点呢？

架构痛点一：代码到处拷贝

举一个最常见的业务例子，用户数据访问，绝大部分公司都有一个数据库存储用户数据，各个业务都有访问用户数据的需求。

在有用户服务之前，各个业务线都是自己通过DAO写SQL访问user库来存取用户数据，这无形中就导致了代码的拷贝。

架构痛点二：复杂性扩散

随着并发量的越来越高，用户数据的访问数据库成了瓶颈，需要加入缓存来降低数据库的读压力，于是架构中引入了缓存，如果没有统一的服务层，各个业务线都需要关注缓存的引入导致的复杂性。

对于写请求，所有业务线都要升级代码：

（1）先淘汰cache；

（2）再写db；

对于读请求，所有业务线也都要升级代码：

（1）先读cache，命中则返回；

（2）没命中则读db；

（3）再把数据放入cache；

这个复杂性是典型的“业务无关”的复杂性，业务方需要被迫升级。

随着数据量的越来越大，数据库需要进行水平拆分，于是架构中又引入了分库分表，如果没有统一的服务层，各个业务线都需要关注分库分表的引入导致的复杂性。

这个复杂性也是典型的“业务无关”的复杂性，业务方需要被迫升级。

典型的耦合，还包括bug的修改，发现一个bug，多个地方都需要修改。

架构痛点三：库的复用与耦合

服务化并不是唯一的解决上述两痛点的方法，抽象出统一的“库”是最先容易想到的解决（1）代码拷贝；（2）复杂性扩散；的方法。

抽象出一个user.so，负责整个用户数据的存取，从而避免代码的拷贝。至于复杂性，也只有user.so这一个地方需要关注了。

解决了旧的问题，会引入新的问题，库的版本维护会导致业务线之间的耦合。

业务线A将user.so由版本1升级至版本2，如果不兼容业务线B的代码，会导致B业务出现问题。

业务线A如果通知了业务线B升级，则是的业务线B会无故做一些“自身业务无关”的升级，非常郁闷。当然，如果各个业务线都是拷贝了一份代码则不存在这个问题。

画外音：有时候拷贝代码也是有好处的。

架构痛点四：SQL质量无法保障，业务相互影响

业务线通过DAO访问数据库，本质上SQL语句还是各个业务线拼装的，资深的工程师写出高质量的SQL，经验没有这么丰富的工程师可能会写出一些低效的SQL。

假如业务线A写了一个全表扫描的SQL，导致数据库的CPU100%，影响的不只是一个业务线，而是所有的业务线都会受影响。

画外音：临时工程序员要背锅了。

架构痛点五：疯狂的DB耦合

业务线不只访问user数据，还会结合自己的业务访问自己的数据。

画外音：user_biz表，也是用uid做主键。

典型的，通过join数据表来实现各自业务线的一些业务逻辑。

业务线A的table-user与table-A耦合在了一起，业务线B的table-user与table-B耦合在了一起，业务线C的table-user与table-C耦合在了一起，结果就是：table-user，table-A，table-B，table-C都耦合在了一起。

随着数据量的越来越大，业务线ABC的数据库是无法垂直拆分开的，必须使用一个大库（疯了，一个大库300多个业务表 =_=）。

架构痛点六：…

服务化后，高可用架构如何？

互联网高可用分层架构演进的过程中，引入了“服务层”。

以上文中的用户业务为例，引入了高可用user-service，对业务线响应所用用户数据的存取。

引入服务层有什么好处，到底解决什么问题呢？

好处一：调用方爽

有服务层之前，业务方访问用户数据，需要通过DAO拼装SQL访问。

有服务层之后，业务方通过RPC访问用户数据，就像调用一个本地函数一样，非常之爽：

User = UserService::GetUserById(uid);

传入一个uid，得到一个User实体，就像调用本地函数一样，不需要关心序列化，网络传输，后端执行，网络传输，范序列化等复杂性。

好处二：复用性，防止代码拷贝

所有user数据的存取，都通过user-service来进行，代码只此一份，不存在拷贝。

升级一处升级，bug修改一处修改。

好处三：专注性，屏蔽底层复杂度

在没有服务层之前，所有业务线都需要关注缓存、分库分表这些细节。

在有了服务层之后，只有服务层需要专注关注底层的复杂性了，向上游屏蔽了细节。

好处四：SQL质量得到保障

原来是业务向上游直接拼接SQL访问数据库。

有了服务层之后，所有的SQL都是服务层提供的，业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话，可以由更资深的工程师维护，而不是像原来SQL难以收口，难以控制。

好处五：数据库解耦

原来各个业务的数据库都混在一个大库里，相互join，难以拆分。

服务化之后，底层的数据库被隔离开了，可以很方便的拆分出来，进行扩容。

好处六：提供有限接口，无限性能

在服务化之前，各业务线上游想怎么操纵数据库都行，遇到了性能瓶颈，各业务线容易扯皮，相互推诿。

服务化之后，服务只提供有限的通用接口，理论上服务集群能够提供无限性能，性能出现瓶颈，服务层一处集中优化。

服务化不能解决所有问题，如果没有碰到这些问题，架构未必需要服务化。

一切脱离业务的架构设计，都是耍流氓。

为什么要微服务（服务化）？相关推荐

布道微服务_01单体到服务化的演进
文章目录小白的困惑 ??? What 定义单体vs微服务服务化微服务 How 服务化拆分的思路纵向拆分横向拆分前置条件小白的困惑 ??? 提到微服务等新技术,大部分人的反应先是惊喜,继 ...
SOA VS 微服务
微服务是近几年非常火热的架构设计理念,大部分人认为是 Martin Fowler提出了微服务概念,但事实上微服务概念的历史要早得多,也不是 Martin Fowler创造出来的, Martin Fow ...
微服务时代组件化和服务化的抉择
作者:vivo 互联网服务器团队-Yao Wenyu 随着业务系统的复杂性越来越高,系统之间的调用也越来越多,在微服务拆分和迭代过程中,是不断的拆分出新的独立的服务还是封装独立的组件以jar包依赖的方 ...
传统服务化（SOA）与微服务（Micro Service）的融合之道
传统服务化(SOA)与微服务(Micro Service),并不是相互排斥的,相反,它们是融合在一块的. 国富论与IT企业组织架构经济学鼻祖亚当斯密在其<国富论>著作中,第一章就是论分工 ...
华为架构师8年经验谈：从单体架构到微服务的服务化演进之路
本次分享的技术大纲如下: 传统应用开发面临的挑战服务化实践服务化不是银弹服务化架构的演进方向一 .传统应用开发面临的挑战挑战1-- 研发成本高主要体现在如下几个方面: 代码重复率高在实际 ...
传统服务化（SOA）与微服务（Micro Service）的融合之道 1
传统服务化(SOA)与微服务(Micro Service),并不是相互排斥的,相反,它们是融合在一块的. 国富论与IT企业组织架构经济学鼻祖亚当斯密在其<国富论>著作中,第一章就是论分工 ...
微服务配置中心是干啥的_微服务化改造系列之三：配置中心
配置中心概述这篇文章是微服务化改造系列的第三篇,主题是配置中心.上一篇我们谈到服务注册中心,即通过提供某种注册和发现的机制,解决服务互通的问题.那么问题来了,一个服务如何知道服务注册中心的地址呢?这 ...
网易云容器服务微服务化实践—微服务测试及镜像化提测全流程实践
前言近几年,互联网项目很多都有从单体服务转变成微服务化的趋势,尤其是一些架构复杂,业务比较广泛的项目,微服务化是大势所趋,可以解决独立构建.更新.运维等一系列问题,从而解放生产力,促进交付效率和质量 ...
服务化架构、SOA、微服务是什么关系
服务化架构.SOA.微服务是什么关系小结:服务化架构是宏观目标,SOA与微服务架构是落地实现.服务化架构-强调对业务垂直拆分形成多个服务模块.然而分布式子系统没有标准,需要一个平台例如ESB,提供中 ...
为什么要微服务架构服务化？
微服务架构,这 5 年左右一直被认可,是软件架构的未来方向.需要大家理解的是,为什么需要服务化.比如微服务架构对企业来说,带来什么价值?有啥弊端? 这里浅谈一下微服务架构,主要还是在理解 Why :为 ...

为什么要微服务（服务化）？

服务化后，高可用架构如何？

为什么要微服务（服务化）？相关推荐

最新文章

热门文章