快速成为顶级架构师的内功修炼
查看直播——如何构建普适的企业级微服务架构
查看下篇文章
孙玄在2010年从浙江大学毕业后，就加入了百度，之后又加入过58集团、转转担任最高级别架构师，最后选择了自己创业，成立了新的IT在线教育平台——奈学教育，致力于IT教育事业，在架构领域有着丰富的经历和独到的见解。
一、微服务架构下服务设计实践
既然我们要构建一个普适的微服务架构，那么如何去体现其“普适性”呢？有没有一些比较通用的微服务架构来帮助我们完成这项任务呢？
首先我们要了解什么是微服务架构，其最经典的定义如下图所示。从定义上我们可以看出，微服务架构是一种将单体架构拆分成一系列小服务组合的方法。那么，我们要如何去定义这个“小服务”呢？也就是说从一个单体变成很多小服务，我们要如何进行拆分呢？实际上，作为一个架构师，主要任务就是“拆”与“合”，如果做好了这两点，就是一名优秀的架构师。
（一）如何“拆”？
有些公司的架构师会进行“甩锅式”的拆分——定量拆分，比如说每一千行代码进行一次拆分，但是会遇到一些问题，比如代码行数不太“完美”，可能刚好在拆分后多了一行。虽然定量拆分是一种可行的拆分方式，但是可以说一定不是一种很好的拆分方式，或者说不是一种“优雅”的拆分方式。
无论何种事物，在底层的设计和“道”上都是相通的，唯一不同的在于“术”，只要我们把其中的一个方面吃透，再迁移到其他方面也是没有问题的。
在讲MS之前，我们先讲讲DB。假设你在负责一个电商的DB建设：你的数据有商品相关的、用户相关的、交易相关的，一开始业务量比较小的时候，可以用一个单独的数据库，其中包括一个商品相关的表、一个用户相关的表、一个交易相关的表。但是随着业务量的增加，请求数也急剧增加，这时候你自然会想到将商品相关的数据、用户相关的数据、交易相关的数据分别存入一个单独的数据库，就有了DB1、DB2和DB3，这种方法叫“分库”。然而，随着用户数的进一步增加，DB2（用户相关的DB）中的数据量过大，都放在一个表中会严重影响数据库性能，这时你发现每一个用户都有一个唯一的User ID，于是按照一定数目将用户信息放在不同的表中，完成了拆分，这种方法叫“分表”。
上面的“分库”方法是对数据库的垂直拆分，“分表”是对数据库的水平拆分。大家类比一下，既然数据库可以进行垂直的拆分和水平的拆分，那么微服务架构是否也可以进行“垂直”和“水平”的拆分呢？答案是肯定的，前面我们说过，他们在“道”上是相通的，区别在于“术”。
假设我们在负责一个电商业务架构，其中包括与用户相关的功能、与商品相关的功能和与交易相关的功能。刚开始所有的请求都依靠一个单体来完成，随着请求数的增加，我们要进行架构的拆分。正如上面讲的，这时候我们至少要进行“垂直”和“水平”的拆分。
（1）垂直拆分
根据具体情况，这时候我们的垂直拆分要按照业务来进行拆分。我们知道，用户和商品之间是逻辑关系，商品和交易之间也是逻辑关系，因此我们可以对其进行拆分，如下图所示，对单体进行简单的垂直拆分。
正如上图我们将单体垂直拆分为用户服务、商品服务和交易服务三部分，但是拆分的粒度比较粗，我们需要更细粒度的拆分。
比如用户服务部分，主要包括用户注册、用户登录、用户查询等服务，其中用户注册是属于“写”的服务，用户登录和用户查询是属于“读”的服务，而一般情况下用户注册是比较重要的，也就是“写”服务的重要性要大于“读”服务；但是如果是一个互联网业务，一般来讲“读”服务的数据量要远远大于“写”服务的数据量，这时候如果用户服务中同时包含了注册和登录服务，那么当登录服务的请求量足够大的时候，一定会影响到注册服务，因此我们可以按照功能对用户服务模块进一步的拆分，比如拆分成用户注册的微服务和用户登录/用户查询的微服务，实际上就是按照API的粒度进行拆分。
那么是不是所有的服务都要按照API的粒度进行拆分呢？当然不是，我们要根据场景来进行拆分，比如业务量比较小的时候，即便用户注册和用户登录在同一个微服务下也不会影响，就不需要进行更细粒度的拆分。
如下图所示，我们对用户服务进行了更细粒度的拆分，但是也许商品的发布量和交易量没有达到一定数量级，就不需要进行更新粒度的拆分。
（2）水平拆分
我们仔细思考上面的例子，如果仅仅做一个垂直拆分，无非是将一个单体变成了多个单体，粒度仍然是比较粗的。这个时候，我们可以从整个请求的生命周期来看看，到底经历了哪几个过程，然后进行拆分，也就是做水平拆分。
我们把商品中的一件衣服拿出来作为例子，假设我们要发布一个商品，它的整个生命周期是怎么样的呢？
如下图所示，我们在APP上发布商品，然后借助通讯协议、传输协议与网关层进行消息传递，网关层完成鉴权、请求参数检查等服务之后与业务逻辑层进行消息传递，业务逻辑层主要负责业务编排等服务，之后再发送请求给数据访问层，数据访问层完成CRUD、sharding、屏蔽底层数据差异性等功能，并从数据层获取数据，数据来源可以是DB、Cache等等。
根据商品发布服务的整个生命周期，我们在架构侧完成了如下图所示的水平拆分。那么类似的，我们的用户相关服务、交易相关服务也可以按照网关层、业务逻辑层、数据访问层等进行相应的水平拆分。其中，网关层在商品相关服务和用户相关服务、交易相关服务是相同的，我们可以将其部署成一个SaaS层，降低架构的工作量。
