什么是微服务?
微服务就是用一组小服务的方式来构建一个应用,服务独立运行在不同的进程中,服务之间通过轻量的通讯机制(如 RESTful 接口)来交互,并且服务可以通过自动化部署方式独立部署。
背景
Docker容器技术的发展有效解决了服务粒度细、服务数量多所导致的开发环境搭建、部署、运维成本高的问题。敏捷、精益、持续交付、DevOps是微服务的催化剂,起到了推动作用。
微服务架构有哪些特征?
- 服务实现组件化
- 按业务组织团队
- 关注产品而非项目
- 技术多样性
- 去中心统一化,业务独立
- 基础设施自动化
- 演进式架构
为什么要使用微服务架构?
单体式应用:
- 系统复杂,耦合度高,开发水平不一导致性能低下[不利于持续开发];
- 运维困难[不利于持续部署];
- 无法扩展[采用新架构和语言非常困难];
- 不可靠[一个内存泄露有可能弄垮整个进程、应用];
微服务架构:
API Gateway-[负载均衡,缓存,路由,访问控制,服务代理,监控,日志等];
API GW / API 网关,顾名思义,是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务,这里的边界是企业 IT 系统的边界,主要起到隔离外部访问与内部系统的作用。
Scala Cube 3D模型[X轴由负载均衡器后端运行的多个应用副本组成,Y轴代表将应用分为微服务,Z轴是将需求路由到相关服务];
每种服务都有自己的数据库,每种服务可以用更适合自己的数据库类型,也被称作多语言一致性架构。比如,驾驶员管理(发现哪个驾驶员更靠近乘客),必须使用支持地理信息查询的数据库。
总结
单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用,就会出现上面描述的不足。
微服务架构模式可以用来构建复杂应用,当然,这种架构模型也有自己的缺点:微服务应用是分布式系统,由此会带来固有的复杂性;微服务的挑战来自于分区的数据库架构;微服务架构模式应用的改变将会波及多个逻辑相关的服务;测试和部署一个基于微服务架构的应用也是很复杂的任务。