大话微服务：（七）规模不大的单体程序推荐也用微服务技术这是一个趋势---单体内部微服务设计方案

参考了一篇优透博文：https://mp.weixin.qq.com/s/9FT6jAU89Y9pBxiiJ0NzfQ

前言：

  微服务技术要不要用，由以下产品决定的：

    （1）必须用：单体程序团队太大了，没法管理，所以一开始就规划好，每个团队负责几个微服务。

     （2）变通用：可能只有一个团队，没有几个人，又想未来单体能拆出来形成一个个微服务，前期按单体应用来开发，这时候就是前期设计思想采用了微服务技术来设计，但开发，运维更象还是单体应用开发，后面没法管理时，把原来逻辑设计好的模块独立出来就形成了一个个微服务。

一、什么叫内部微服务设计？

     这种设计表面上看起来是一个单体程序，它只有一个源代码存储仓库，一个数据库，一个部署，但在程序内部可以按照微服务的思想来进行设计。它可以分成多个模块，每个模块是一个微服务，可以由不同的团队管理。

二、内部微服务的思想是什么？

•      一个单体程序由 各个模块组件构成，每一个模块就是一个微服务，它可以由不同的团队来开发与管理。
•     一个模块未来就是可能独立抽出来的单体程序形成一个微服务，每一个模块都有自己的一套数据库表，但模块之间不能跨数据库访问（不要建立模块之间数据库表的外键）。
•    多个模块之间有共享的实体类，根据DDD的上下文约定原则，不建议共享，虽然数据大致相同，应在不同的模块中采用不同的名字。
•   内部微服务，说白了就是用DDD，注重业务逻辑上的设计。 

三、内部微服务特点：

     这样设计的好处是它是一个单体程序，省去了多个微服务带来的部署、运维的麻烦。但它内部是按微服务设计的，如果以后要拆分成微服务会比较容易。至于什么时候拆分不是一个技术问题。

四、何时把它独立出来，形成真正的微服务？    

       如果负责这个单体程序的各个团队之间不能在部署时间表，服务器优化等方面达成一致，那么就需要拆分了。

当然你也要应对随之而来的各种运维麻烦。内部微服务设计是一个折中的方案，如果你想试水微服务，但又不愿意冒太大风险时，这是一个不错的选择。