漫谈微服务

前言

印象中从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通讯方式，轻量级，且与平台和语言无关，几乎没有学习的成本。

若是须要异步的通讯方式推荐使用消息队列，生产者和消费者异步有利于提升整个系统的性能，可是须要学习消息队列的用法，而且作好选型，还需考虑消息队列的高可用等等。