漫谈微服务

前言

印象中从2016年开始“微服务”这个词逐渐为人们所熟知，那究竟什么是微服务呢？

微服务是一种软件架构风格，一种架构模式，提倡将单体应用划分为一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），通信的方式应该与语言无关（C/C++/Golang/Python...），与平台无关（Windows/Linux/AIX/Android...）。

每个服务都围绕这具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

传统单体应用存在的问题

传统三层架构图

三层架构通常包括表示层（UI），业务逻辑层以及数据访问层。主要面临的问题：

• 维护成本高。随着应用程序功能越来越多，系统间耦合紧密，团队越来越大，相应的沟通成本，人员协调成本必然会显著增加。
• 技术选型成本高。各业务领域需要使用相同的技术栈，难于快速应用新技术，阻碍创新。
• 运维成本高。对应用的任何修改都必须整个应用一起部署/升级。
• 可扩展性差。当应用负载增加时，难以水平扩展。例如有些模块对CPU要求高，有些模块对IO要求高，绑定在同一个进程里面就必须同时满足CPU密集型和IO密集型的要求，对机器要求高。
• 一处出现问题会导致整个应用不可用。例如任务一个模块的逻辑coredump都会导致整个程序崩溃。

微服务架构的优势

微服务架构图

• 独立性。每个服务都是独立的业务单元，能够被独立地开发、测试、构建，并且能够被直接部署。
• 单一职责。每个服务聚焦于某个业务功能，通过清晰的边界划分，更容易被团队理解和维护。
• 技术多样性。通过服务之间的协作以及轻量级的通信机制，组织或者团队能使用合适的语言、工具解决业务问题。

微服务的挑战

• 分布式系统的复杂度。微服务架构是一种分布式系统，从交付的角度出发，构建分布式系统必然会带来额外的开销，例如性能（进程内通信VS跨机通信），可靠性（远程访问的可靠性），数据一致性（不同节点间数据同步问题）等等。

• 运维成本。进程一拆为多之后，对应的部署成本和监控告警与日志采集的成本都会成倍上升。
• 服务重构成本。传统的应用需要重构成微服务，由改造成本。
• 服务治理相关成本。配套的服务注册与发现，服务网格，服务编排构建。

微服务其实不算是一个全新的概念，早在1996年，Gartner就提出了面向服务架构（SOA），阐述了“对于复杂的企业IT系统，应按照不同的、可重用的力度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务”。既然相关的概念早就有了，那为什么微服务是最近几年才火爆起来呢？

因为抛开自动化的CI/CD，相关的服务网关，服务注册与发现 去空谈微服务是没有办法精准落地的，得益于2014年Docker的横空出世解决了应用打包问题，2016年K8S在容器编排大战中完胜Mesos和Swarm，微服务相关的生态才被完美建设起来，才有了精准落地的可行性。

微服务通信

微服务架构的本质是分布式系统，随着系统复杂度的增加以及微服务数量的增多，如何选择轻量级通信机制、完成服务和服务之间的协作和交互越发重要。这里主要比对RPC（例如Thrift），RESTful HTTP，消息队列（例如beanstalk/redis）。

	RPC（远程方法调用）	REST	消息队列
通信方式	同步通信	同步通信	异步通信
平台依赖性	强	平台无关	强
语言支持	好	语言无关	好
学习成本	高	低	高
维护成本	高	低	高

 

如果是同步的通信方式推荐使用RESTful HTTP通信方式，轻量级，且与平台和语言无关，几乎没有学习的成本。

如果需要异步的通信方式推荐使用消息队列，生产者和消费者异步有利于提高整个系统的性能，但是需要学习消息队列的用法，并且做好选型，还需考虑消息队列的高可用等等。