微服务架构软件的持续集成与交付微服务架构软件的持续集成与交付
微服务架构概述
今天是 Mesos 生态圈系列的第二次分享,这次分享的内容是微服务架构软件的持续交付,我首先解释下标题与 Mesos 生态圈
的关系。微服务架构是近几年讨论比较多或者说比较受欢迎的一种软件架构风格,但是该架构有一些缺点,譬如运维复杂度提
高,交付次数频繁等,我们可以利用 Mesos 配合一些工具搭建持续交付平台来弥补这些缺点。这里我将以具体实践为例,讨
论微服务架构的一些经验心得,然后着重介绍如何利用 Docker,Jenkins 来解决一些具体问题,实现微服务软件的持续交
付。
首先介绍下微服务架构的优势与劣势。相较于单体应用来说,微服务架构有这么几个优点:
1.易于开发、理解。 由于每个服务只负责单一功能,开发者可以聚焦于自己负责的几个服务模块,对于其他服务,只需要理
解接口即可。当然,单体应用经过良好设计也可以达到这个效果,但是,与单体应用的进程内通信或单机内的进程间通信不同
的是,微服务的各服务之间一般采用 RESTfulAPI或者异步消息队列进行通信,无论 RESTful接口还是异步消息队列都是开发
语言无关的,极易理解的通信方式。
2.全局稳定性提高。由于每个服务负责的功能单一,各服务的资源需求也相对更低。从而可以选择将服务分散的部署到多台中
低配的服务器上,而不是一台高配的机器上。如果某个机器上的服务故障,譬如说内存泄漏,故障只会影响该机器上的某一个
或几个服务,对全局影响不大。
3.不受限于任何技术栈,极大的提高团队搭建的速度。这一点对初创公司尤为重要,组建开发团队对初创公司来说本来就是个
头疼的问题,如何还要求团队的技术栈一致,招聘难度可想而知。但是,如果产品架构采用微服务架构,那么我们可以允许不
同的服务模块采用不同的技术栈,只需要定义好对外接口即可。
4.局部的修改很容易部署,从而大大的提高了功能的交付效率。
说完了微服务架构的优点,我们再来讨论下其缺点或者说复杂的地方:
1.如何确定软件功能切分的粒度,边界。太多的微服务模块会导致服务间通信成本和运维成本的增加,过犹不及;但是若粒度
过大,又违背了微服务的初衷。
2.多种技术栈(譬如 C,Java,Python,Scala 等)我们需要为每种语言准备编译环境,运行环境等,增加了维护成本。这个
可以通过Docker 隔离来解决,我们后面会详细展开。
3.微服务模块多了,会导致全局的上线次数变多,从而需要更复杂的版本管理和 Bug跟踪等,间接导致项目管理成本增加。