如果你真的要做微服务,那你一定逃不掉这个阶段。(如果你连这个都没到,那就别瞎想了哈)
第一阶段的三大特征:
(物流行业有一定规模自主研发团队的,90%处于这个阶段)
2.1. 阶段一的组织状态
组织状态相对简单。
统一的运维组,管理物理机,物理网络,Vmware虚拟化等资源,同时部署上线由运维部负责。
开发组每个业务都是独立的,负责写代码,不同的业务沟通不多,开发除了做自己的系统外,还需要维护外包公司开发的系统,由于不同的外包公司技术选型差异较大,因而处于烟囱式的架构状态。
传统烟囱式架构如下图所示
2.2. 阶段一的运维模式
在传统架构下,基础设施层往往采取物理机或者虚拟化进行部署,为了不同的应用之间方便相互访问,多采取桥接扁平二层机房网络,也即所有的机器的IP地址都是可以相互访问的,不想互相访问的,多采用防火墙进行隔离。
无论是使用物理机,还是虚拟化,配置是相对复杂的,不是做过多年运维的人员,难以独立的创建一台机器,而且网络规划也需要非常小心,分配给不同业务部门的机器,网段不能冲突。所有这一切,都需要运维部门统一进行管理,一般的IT人员或者开发人员既没有专业性,也不可能给他们权限进行操作,要申请机器怎么办,走个工单,审批一下,过一段时间,机器就能创建出来。
2.3. 阶段一的应用架构
传统架构数据库层,由于外包公司独立开发,或者不同开发部门独立开发,不同业务使用不同的数据库,有用Oracle的,有用SQL Server的,有用Mysql的,有用MongoDB的,各不相同。
传统架构的中间件层,每个团队独立选型中间件:
传统架构的服务层,系统或者由外包公司开发,或者由独立团队开发。
传统架构前端,各自开发各自的前端。
2.4. 阶段一有什么问题吗?
其实阶段一没有任何问题,我们甚至能找出一万个理由说明这种模式的好处。
运维部和开发部是天然分开的,谁也不想管对方,两边的老大也是平级的,本相安无事。
机房当然只能运维人员能碰,这里面有安全的问题,专业性的问题,线上系统严肃的问题。如果交给没有那么专业的开发去部署环境,一旦系统由漏洞,谁能担责任,一旦线上系统挂了,又是谁的责任,这个问题问出来,能够让任何争论鸦雀无声。
数据库无论使用Oracle, DB2,还是SQL Server都没有问题,只要公司有足够的预算,而且性能也的确杠杠的,里面存储了大量存储过程,会使得应用开发简单很多,而且有专业的乙方帮忙运维,数据库如此关键,如果替换称为Mysql,一旦抗不出挂了,或者开源的没人维护,线上出了事情,谁来负责?
中间件,服务层,前端,全部由外包商或者乙方搞定,端到端维护,要改什么招手即来,而且每个系统都是完整的一套,部署方便,运维方便。
其实没有任何问题,这个时候上容器或者上微服务,的确自找麻烦。
2.5. 什么情况下才会觉得阶段一有问题?
当然最初的痛点应该在业务层面,当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现自己或者外包公司不是能完全搞定所有的事情,他们是瀑布模型的开发,而且开发出来的系统很难变更,至少很难快速变更。
于是你开始想自己招聘一些开发,开发自己能够把控的系统,至少能够将外包公司开发的系统接管过来,这个时候,应对业务部门的需求,就会灵活的多。
但是自己开发和维护就带来了新的问题,多种多样的数据库,根本不可能招聘到如此多样的DBA,人都非常的贵,而且随着系统的增多,这些数据库的lisense也非常的贵。
多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA。一旦使用的消息队列,缓存,框架出了问题,整个团队没有人能够搞定这个事情,因为大家都忙于业务开发,没人有时间深入的去研究这些中间件的背后原理,常见的问题,如何调优等等。
前端框架也有相同的问题,技术栈不一致,界面风格不一致,根本无法自动做UI测试。
当维护了多套系统之后,你会发现,这些系统各个层次都有很多的共同点,很多能力是可以复用的,很多数据是可以打通的。同样一套逻辑,这里也有,那里也有,同样类型的数据,这里一份,那里一份,但是信息是隔离的,数据模型不统一,根本无法打通。
当出现这些问题的时候,才是您考虑进入第二个阶段。