微服务生态体系建设之 三个火枪手（4） 总结

前文说到，微服务、容器、和DevOps这三个火枪手，他们互为绝配，三人同行，立马成为铁三角，所向披靡。

 

 

 

 

然而，事物的发展总是那么曲曲折折。事实上

• 在应用模式上，经历了从单体应用到SOA再到微服务三个阶段(对于我们来说，SOA基本可以忽略)；我们自己大量存在的单体应用，而由我们提供基础服务的那个业务部门主要是微服务应用；
• 在基础架构上，我们经历了从实体机(虚机)环境一步跳到架构在超融合主机群之上的Openshift容器云环境的阶段，然后现在再回头规划构建IaaS混合云平台提供虚机服务。我们依旧大量使用实体机及实体机下的虚机资源，IaaS还在建设中。而由我们提供基础服务的那个业务部门则正在使用openshift容器云环境；
• 在DevOps上，我们至今还在经历需求开发、测试、发布、运维等被隔离在不同团队，完全通过手工、线下流程进行运作的模式。目前只是在测试环境发布时在Jenkins上写了个脚本进行发布，并没有把任何环节打通。随着IaaS平台的建立，U2L的落实，用运维自动化工具Ansible之类的工具进行持续部署和运维正在变成可能。而如上文所言，由我们提供基础服务的那个业务部门已经开始使用基于Jenkins的“狭义”DevOps的模式。未来如果向前再和Jira敏捷需求和产品管理工具连接，向后再和普罗米修斯Prometheus和grafana监控报表平台打通，自身再在Jenkins外面包个平台出来，进行配置管理、环境管理、资源管理、监控日志管理，那么广义的DevOps模式也就成了。

世界充满着多样性。在IT的世界里，事物同样是多态的。然而，不看不知道，一看吓一跳，事实是如此地残酷。

 

	应用模式	开发模式	代码管理	集成模式	基础架构	DevOps	IaC（基础架构即代码）	部署环境
第一阶段	单体	瀑布	SVN	ant	实体机（或实机上的虚机）	完全隔离，Jenkins仅用于发布到测试环境	纯手工打造	无开发环境，仅测试生产环境，异构严重
第二阶段	单体	瀑布+敏捷	Git	maven	云上虚机	Jenkins打通开发部署过程	Ansible等自动运维工具	可同构
第三阶段	微服务	敏捷	Git	maven	容器云（openshift)	Jenkins打通开发部署过程	openshift API	完全同构

通过对三个火枪手的考察发现，我们竟然还处在第一阶段，正在艰苦地向第二阶段挺进，而由我们提供基础服务的那个业务部门已经稳稳地坐在了第三阶段，正在向更高阶段进军。幸运的是，以上三点的技术我们牢牢掌握着，只要资源ready，一声令下，我们就可以直接进入第三阶段。当然，第二阶段和第三阶段会并存很长时间，所以向第二阶段的挺进攻坚必不可少！

事物的发展，总是经历着这样的一个上升：通过技术的提高，使最初的艺术技术化，从而解放人类，为人类追求更高的艺术赋能。而这种上升模式，正好是CMMI软件能力成熟度集成模型的精髓。

现在，我们的目标很明确，那就是通过云平台、微服务框架、和敏捷开发部署管理平台的建设，提升开发运维的成熟度，提高软件质量降低TTM时间。

当前正是政通人和、百废俱兴之时，沐浴在“新四化”的春风之中，乘坐在“数字化转型”的巨轮里。“百舸争流，奋楫者先”，时不我待、只争朝夕，我们应奋力夯实数字化技术基础，推动业务的数字化转型，助力数字化业务的发展。

回头来看看，我们第一篇提出的三个问题，大家应该已经找到答案了吧？那个终极问题，大家怎么想？大家有没有想到康威定律？

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

简单来说： 产品必然是其组织沟通结构的缩影。

那么，我们为什么一定要有乙方呢？没有了乙方，我们是不是不用走采购流程了呢？

 

好了，《三个火枪手》就此谢幕。谢谢观赏，敬请点赞。