印象中从2016年开始“微服务”这个词逐渐为人们所熟知,那究竟什么是微服务呢?
微服务是一种软件架构风格,一种架构模式,提倡将单体应用划分为一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。
每个服务运行在其独立的进程中,服务与服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API),通信的方式应该与语言无关(C/C++/Golang/Python...),与平台无关(Windows/Linux/AIX/Android...)。
每个服务都围绕这具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
传统三层架构图
三层架构通常包括表示层(UI),业务逻辑层以及数据访问层。主要面临的问题:
微服务架构图
微服务其实不算是一个全新的概念,早在1996年,Gartner就提出了面向服务架构(SOA),阐述了“对于复杂的企业IT系统,应按照不同的、可重用的力度划分,将功能相关的一组功能提供者组织在一起为消费者提供服务”。既然相关的概念早就有了,那为什么微服务是最近几年才火爆起来呢?
因为抛开自动化的CI/CD,相关的服务网关,服务注册与发现 去空谈微服务是没有办法精准落地的,得益于2014年Docker的横空出世解决了应用打包问题,2016年K8S在容器编排大战中完胜Mesos和Swarm,微服务相关的生态才被完美建设起来,才有了精准落地的可行性。
微服务架构的本质是分布式系统,随着系统复杂度的增加以及微服务数量的增多,如何选择轻量级通信机制、完成服务和服务之间的协作和交互越发重要。这里主要比对RPC(例如Thrift),RESTful HTTP,消息队列(例如beanstalk/redis)。
RPC(远程方法调用) | REST | 消息队列 | |
---|---|---|---|
通信方式 | 同步通信 | 同步通信 | 异步通信 |
平台依赖性 | 强 | 平台无关 | 强 |
语言支持 | 好 | 语言无关 | 好 |
学习成本 | 高 | 低 | 高 |
维护成本 | 高 | 低 | 高 |
如果是同步的通信方式推荐使用RESTful HTTP通信方式,轻量级,且与平台和语言无关,几乎没有学习的成本。
如果需要异步的通信方式推荐使用消息队列,生产者和消费者异步有利于提高整个系统的性能,但是需要学习消息队列的用法,并且做好选型,还需考虑消息队列的高可用等等。