搭建一个完整的微服务系统(一)：系统设计

前言

        网上能检索到各种各样的微服务实战，但都是阐述某一个方面，我将一个真实的跨境支付系统中的C2C国际汇款后台代码部分精炼出来，供大家学习使用，也用来感恩互联网多年来对我开发之路的帮助。
        本系列主要是讲代码部分，所以只在本节对系统架构进行一些简单说明，将来有机会再写系统架构的专题。

系统架构

        这张图对写代码来说，并没有实际指导作用，但我们开发一个系统，开始都要画出一个类似的图，主要是为了向所有关系人讲解系统构成，方便他们理解。
        本系列主要是讲代码层面，我只会在本节对系统架构进行简单说明。从上图可以看出：
            1. 用户用app通过网关接入本系统，而系统通过渠道路由请求不同的上游，运营通过辅助网站运营系统。
            2. 整个系统使用spring cloud来搭建，消息中间件采用Rocket MQ，缓存采用Redis。
            3. 系统模块主要分成两部分：公共服务基本来自业务中台，汇款业务来自业务系统。
            4. 版本管理采用git，部署采用jenkins，日志收集采用ELK。

微服务划分

        怎么划分微服务，有太多的理论。就我个人观点来说，可以从下面三个方面进行考虑：
            1. 如果系统不够复杂，能够从设计上就避免分布式事务，那就按避免分布式事务的方式来划分。
            2. 按业务模块分。这是最见的方式，但如果是一个高频的系统，单纯按业务模块分微服务，是不合理的。
            3. 按业务流程分。一般来说，2C的系统的微服务划分，都需要按业务流程来划分微服务才能最大程度保证系统的弹性。举个例子，手机支付大家都很熟悉，如果把后台交易核心简化，微服务划分就像是如下：

数据库设计

        无论公司业务上是否需要SaaS，将一个系统设计成SaaS系统都是非常必要的，SaaS的应用场景有不少，举两个例子大家就很容易理解了：
            1. 很多人都遇到过测试环境正常，生产环境却出现bug的情况。这时要查原因就很难了(一般只能等晚上业务停止后才能将生产数据拷贝到测试环境去重现bug)，很多人的解决方法是在生产环境上创建测试商户，但这会带来各种各样的问题，比如账务就很难平了。如果系统是SaaS，就没有任何副作用。
            2. 一款系统，国际化是很常见的需求，资源文件的国际化是当然的，但是数据库里保存的文字怎么国际化呢？系统是SaaS也是一个很好的解决方案。

        一般的公司设计SaaS，就是在所有表都加一个字段：租户Id，所有sql文都带上租户id。这种方案感觉上就有点问题，一种更好更简单的方式是：每个租户一个数据库，通过动态切换数据库来切换租户。这样，除了开发框架的组员外，其它业务开发人员完全不用意识到这一点，就可以完成系统的开发。

下一章：搭建一个完整的微服务系统(二)：动态切换数据库