传统企业微服务落地大法（2）-必须经历的第一阶段

如果你真的要做微服务，那你一定逃不掉这个阶段。(如果你连这个都没到，那就别瞎想了哈)

第一阶段的三大特征：

(物流行业有一定规模自主研发团队的，90%处于这个阶段)

单体架构群，多个开发组，统一运维组

2.1. 阶段一的组织状态

组织状态相对简单。

统一的运维组，管理物理机，物理网络，Vmware虚拟化等资源，同时部署上线由运维部负责。

开发组每个业务都是独立的，负责写代码，不同的业务沟通不多，开发除了做自己的系统外，还需要维护外包公司开发的系统，由于不同的外包公司技术选型差异较大，因而处于烟囱式的架构状态。

传统烟囱式架构如下图所示

2.2. 阶段一的运维模式

在传统架构下，基础设施层往往采取物理机或者虚拟化进行部署，为了不同的应用之间方便相互访问，多采取桥接扁平二层机房网络，也即所有的机器的IP地址都是可以相互访问的，不想互相访问的，多采用防火墙进行隔离。

无论是使用物理机，还是虚拟化，配置是相对复杂的，不是做过多年运维的人员，难以独立的创建一台机器，而且网络规划也需要非常小心，分配给不同业务部门的机器，网段不能冲突。所有这一切，都需要运维部门统一进行管理，一般的IT人员或者开发人员既没有专业性，也不可能给他们权限进行操作，要申请机器怎么办，走个工单，审批一下，过一段时间，机器就能创建出来。

2.3. 阶段一的应用架构

传统架构数据库层，由于外包公司独立开发，或者不同开发部门独立开发，不同业务使用不同的数据库，有用Oracle的，有用SQL Server的，有用Mysql的，有用MongoDB的，各不相同。

传统架构的中间件层，每个团队独立选型中间件：

• 文件：NFS，FTP，Ceph，S3
• 缓存：Redis Cluster，主备，Sentinel, Memcached
• 分布式框架：Spring Cloud，Dubbo，Restful or RPC不同的部门自己选型
• 分库分表：Sharding-jdbc，Mycat
• 消息队列：RabbitMQ, Kafka
• 注册中心：Zk，Euraka，consul

传统架构的服务层，系统或者由外包公司开发，或者由独立团队开发。

传统架构前端，各自开发各自的前端。

2.4. 阶段一有什么问题吗？

其实阶段一没有任何问题，我们甚至能找出一万个理由说明这种模式的好处。

运维部和开发部是天然分开的，谁也不想管对方，两边的老大也是平级的，本相安无事。

机房当然只能运维人员能碰，这里面有安全的问题，专业性的问题，线上系统严肃的问题。如果交给没有那么专业的开发去部署环境，一旦系统由漏洞，谁能担责任，一旦线上系统挂了，又是谁的责任，这个问题问出来，能够让任何争论鸦雀无声。

数据库无论使用Oracle, DB2，还是SQL Server都没有问题，只要公司有足够的预算，而且性能也的确杠杠的，里面存储了大量存储过程，会使得应用开发简单很多，而且有专业的乙方帮忙运维，数据库如此关键，如果替换称为Mysql，一旦抗不出挂了，或者开源的没人维护，线上出了事情，谁来负责？

中间件，服务层，前端，全部由外包商或者乙方搞定，端到端维护，要改什么招手即来，而且每个系统都是完整的一套，部署方便，运维方便。

其实没有任何问题，这个时候上容器或者上微服务，的确自找麻烦。

2.5. 什么情况下才会觉得阶段一有问题？

当然最初的痛点应该在业务层面，当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，你会发现自己或者外包公司不是能完全搞定所有的事情，他们是瀑布模型的开发，而且开发出来的系统很难变更，至少很难快速变更。

于是你开始想自己招聘一些开发，开发自己能够把控的系统，至少能够将外包公司开发的系统接管过来，这个时候，应对业务部门的需求，就会灵活的多。

但是自己开发和维护就带来了新的问题，多种多样的数据库，根本不可能招聘到如此多样的DBA，人都非常的贵，而且随着系统的增多，这些数据库的lisense也非常的贵。

多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。一旦使用的消息队列，缓存，框架出了问题，整个团队没有人能够搞定这个事情，因为大家都忙于业务开发，没人有时间深入的去研究这些中间件的背后原理，常见的问题，如何调优等等。

前端框架也有相同的问题，技术栈不一致，界面风格不一致，根本无法自动做UI测试。

当维护了多套系统之后，你会发现，这些系统各个层次都有很多的共同点，很多能力是可以复用的，很多数据是可以打通的。同样一套逻辑，这里也有，那里也有，同样类型的数据，这里一份，那里一份，但是信息是隔离的，数据模型不统一，根本无法打通。

当出现这些问题的时候，才是您考虑进入第二个阶段。