架构

本人目前在单位的服务组，纯后台开发。

与外面同行交流的时候，很多人对于服务(服务组)没有概念，包括公司内部绝大部分人对于服务也没有概念。

甚至都不知道我所在的服务组是做什么的...╮(╯▽╰)╭

之前和组长也探讨过 "什么是服务？" "服务做的是什么？"，组长的回答也是模棱两可。

后来无意中在公众号上看到了一篇文章，加深了我对服务的理解

下面通过公众号"架构师之路"《互联网架构为什么要做服务化？》我们来理解下服务的概念

1. 互联网高可用架构，为什么要服务化？

在服务化之前，互联网的高可用架构大致是这样子的...

a. 用户端就是chrom浏览器或者App客户端。
b. 后端入口是高可用nginx集群，用作反向代理。
c. 中间的核心是高可用web-server集群，就是普通web项目的mvc那三层，研发工程师编码工作主要就是这里。
d. 底层存储是高可用db集群。

一般普通常见的Web项目，在MVC里面，通过jdbc或者ORM框架(Hibernate，MyBatis)去访问数据库

这种普通的架构有什么缺陷，或者说有没有什么用的不爽的地方呢？

【架构痛点一：代码到处拷贝】
举个栗子：

大部分公司的数据库里面都会存储用户的数据，各个业务都有访问用户数据的需求：

这时候，各个业务线都是通过DAO层编写SQL语句访问User库来操作用户数据，这样子无形中导致了代码的拷贝。
(在大公司的web项目中，因为业务模块庞大，每个业务模块都是按组进行分工的)

【架构痛点二：复杂性扩散】
随着并发量越来越高，用户数据访问数据库成了性能瓶颈，需要加入缓存来降低数据库的读写压力，

于是架构中加入了缓存，由于没有统一的服务层，各个业务线都需要关注缓存的引入导致Dao层的复杂性。

对于用户数据的写入求，所有业务线相关代码都需要升级
i. 先淘汰cache缓存数据
ii. 在写入数据

对于用户数据的读取请求，所有业务线相关代码也都需要升级
i. 先从cache缓存中读取，命中则返回
ii. cache缓存没有命中，则读取数据库
iii. 然后将数据库中取出的数据，存入cache缓存

这个复杂性是典型的"业务无关"的复杂性，业务方需要被迫升级。
(因为作为业务层面讲，完全不需要关心)

随着数据量越来越大，数据库需要进行水平拆分，于是架构中又引入了分库分表，由于没有统一的服务层，

各个业务线都需要关注分库分表的引入导致的复杂性

这个架构的改动，也是典型的"业务无关"的复杂性，业务方需要被迫升级。
当然也包括bug修改，发现一个bug，很多地方都需要修改。
因为有些SQL或者业务处理是相同的，有些程序员会直接复制代码╮(╯▽╰)╭


(原文中第三点，数据库版本什么的，有点看不明白，这里省略，有兴趣的童鞋可以看下原文)
【架构痛点三：SQL质量得不到保证，业务互相影响】

所有的业务线都是通过DAO层访问数据库的：

也就意味着，本质上讲，SQL语句是各个业务线自己拼接的，资深的开发写出高质量的SQL没啥问题，
不过经验不够的开发可能会写出质量低的SQL。
举个栗子：
假如业务A写了一个全表扫描的SQL，导致数据库的CPU飙升100%，这样子会影响其他所有的业务线对数据库的访问。


【架构痛点四：疯狂的DB耦合】

业务线不止需要访问User用户数据，还会结合自己的业务访问自己的数据：

典型的，例如多表、主外键关联等等通过join数据表来实现各自业务线的一些业务逻辑。
这样的话，业务线A的table-user与table-A就耦合了，同样，业务线B，业务线C也都耦合。

随着数据量越来越大，业务线ABC的数据库无法垂直拆分，必须使用一个大库。

........

2. 服务化解什么问题？

为了解决上面诸多的问题，互联网高可用分层架构演进的过程中，引入了"服务层"

加入了服务层，有什么好处呢？

【好处一：调用方便】
有服务层之前：业务层访问User用户数据，需要自己通过Dao层，拼接SQL，对数据库进行访问。

有服务层之后：业务层通过RPC访问用户数据，就像调用本地函数方法一样方便。
User user = userServiceClient.getUserById(uid)
传入一个用户ID(uid)，得到一个User实体，就像调用本地函数方法一样，不需要关心序列化，网络传输，后端执行，网络传输等复杂性。


【好处二：复用性、防止代码到处拷贝】
这个很明显吧，使用服务层之后，所有的业务线通过服务层访问数据库，不需要自己访问数据库，自然提高了代码的复用性。
还有如果服务层发现了一个BUG之后，只需要在服务层一处修改即可，业务层完全不用改动。


【好处三：专注性，屏蔽底层复杂度】
在没有服务层之前，所有的业务线都需要关注缓存、分表分库等细节。

在有了服务层之后，只需要服务层去关注底层的复杂性即可，业务层什么都不用管，向上游屏蔽了底层的细节。

【好处四：SQL质量得到保证】
没有服务层之前：业务层直接拼接SQL访问数据库

有服务层之后：所有的SQL都是服务层提供、维护，业务层对于SQL，不再为所欲为。

【好处五：数据库解耦】
有服务层之前，原有的业务在数据库中互相混合，互相join，难以拆分

有服务层之后，底层数据库被隔离，可以很方便得对数据库进行拆分，进行扩容

【好处六：提供有限接口、无限性能】
在服务化之前，业务线层想怎么写SQL都行，遇上了性能问题，肯定会互相推锅扯皮。

服务化之后，服务只提供有限的接口，李俊上服务集群能够提供无限的性能，当性能出现瓶颈，服务层进行统一优化处理。

最后是目前**的一个架构