进行微服务化构建应用的时候需要考虑哪些内容？

Question

在提问问题之前，自己查阅了比较多的有关微服务的概念、模式、实践方法（大概的实践方法），但是面对实际的应用场景的时候，对于服务的拆分和部署等仍然有一些疑惑的问题。

提交问题的时候才发现这么多内容，只是对其中一点讲解一下也是可以的。如果有合适的资料也可以推荐我看一下，我去多看多理解。如果有愿意全面讲解的，我也很乐意以付费咨询的形式去沟通。

1、对应用进行拆分的时候，依据什么？

有的文章会建议从“服务”的角度去拆分，比如读写服务、日志服务等，有的文章上建议从功能的角度去拆分，如不同的功能拆成不同的微服务（有点儿模块化的概念）。

我个人的理解是，对应用进行微服务拆分的时候，如果是从功能的角度去进行拆分相对而言更加的直观，（但是我自己有点儿陷进模块化的这种概念了）。

2、数据库是共享还是拆分？

自己接触最多的就是单体应用，或者直白点说就是，一个简单的 web 应用（网站），以 PHP 举例，配好服务器，开启 mysql，写代码，部署上线....等就完成了。数据库就一个，基本上保存了所有内容。

在微服务的这种思想下，我看很多资料是支持每个服务有自己的数据库，而不是去共享，我自己比较赞同这点，因为微服务本身就是一个独立运行的个体，无非暴露API，但是这种数据库拆分又应该如何做呢？

是概念的拆分（实际共享）还是物理的拆分？

我是这样子理解的，如果是概念的拆分，数据库还是跑在一个 mysql 上，然后每个微服务去管自己的逻辑就好，（我不确定这是否能够成为拆分），好处是数据库的内容是共享的，不过这个应该也违背了每个微服务都能够单独运行的思想。

下面是我自己无法理解的地方：

如果说每个微服务跑自己的数据库（也可能不是关系型数据库而是其他k-v存储），这种方式又当如何去拆分呢？

如果我的微服务部署在容器中，那岂不是每个容器都要跑一个 mysql？

即使能够允许每个容器跑一个 mysql ，那我的数据存储和传统的数据存储有哪些区别呢？比如传统的过程中可能通过 uid 关联其他的表内容，当我分开之后，还是使用 uid 关联 是否恰当？

3、开发语言和组织形式

这也是我的一个模糊的概念，现在微服务更推出 spring boot 或 spring cloud，或 go 或 node，有人也通过 php 搞过微服务框架如：php-msf。

我想知道的是，每个微服务使用什么语言是无所谓的，关键是要提供能够正常使用的接口API 这个说法是否正确。

其次，如果说我使用非常笨的方式：

将每个功能进行拆分，然后去实现每个功能，然后跑在 docker 或者是其他方式运行起来，这能否称为微服务？

4、实际的应用场景

我最近遇到了一个比较实际的应用场景，抽象出来的功能主要下面几部分：

• 用户填写相关信息并且能够上传图片（这里不考虑登录注册等功能）

• 根据上传的图片进行 OCR 文字识别

• 根据识别出来的文字匹配一个建模库（这个建模库只是笼统称呼）

  • 这个功能的本质就是，传递一组数据，返回对应的结果

从这点来看，上面主要是三大功能，如果按照传统端单体应用来开发，则非常方便，就是不同的 Controller 调用然后 Model 数据查询更新就行了。

如果说强制的进行微服务化，那这个场景需要如何考虑呢?

我自己能够想到的部分如下：

1. 用户填写和上传图片可以作为一个或者两个为服务，考虑到上传可复用性非常强，单独做一个微服务出来。

这里问题来了,按照传统的单体应用，写两个controller和model操作即可，比如用户 uid 关联其上传的 media 表。

如果需要微服务，则我上传图片的这个微服务的数据库应该怎么设计或者分离出来？是应当使用mysql还是使用k-v存储，最终是上传到服务器上把图片，然后这图片路径如何与uid进行关联呢？

还是说图片上传成功之后，我返回图片的路径，然后在原来的数据表中关联这个路径比较合适？

2. OCR 文字识别可以是自己部署开源的引擎，也可以使用第三方API。因此进行微服务化。

这个是我最清晰知道如何做的部分，提供API即可，也不需要数据库。

3. 匹配建模库，返回数据，这个也不需要数据存储，提供API即可

问题比较多也比较杂，主要是对微服务实践应用方面有比较模糊的概念

Answer 1

个人觉得，如果单体应用够用的话，如业务上没有需要，不建议微服务化、Docker化。