微服务简介
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
应用架构发展
单体架构
单体应用 就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中。最终经过编译、打包,部署在一台服务器上。典型例子是j2ee的war包或ear包。
在应用的初始阶段,单体架构无论是在开发速度、运维难度上,还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段,用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高,这种架构明显存在很多的不足,主要体现在以下3个方面。
- 缺点:
- 随着业务扩张,开发难度加大,动一发而迁全身,代码的可读性、可维护性和可扩展性下降,业务扩展带来的代价越来越大,开发都在同一个项目改代码,相互等待,冲突不断。
- 部署启动时间较长,期间服务会中断,模块间相互影响较多,测试难难度加大,一个微小的问题,都可能导致整个应用挂掉。
- 性能容量有限,无法满足高并发下的业务需求,受单机限制(纵向扩展),有性能瓶颈。
集群架构
随着业务的发展,大多数公司会将单体应用进行集群部署,并增加负载均衡服务器(例如Nginx、F5等),以应对用户量的增加而带来的高并发访问量。此时的系统架构如图1-3所示。
- 优化策略:
- 负载均衡,通过分发服务器,将用户的访问分派到不同的应用服务器,应用服务器的负载不再成为瓶颈,用户量增加时,添加应用服务器即可。
- 添加缓存,使用缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的,但是仍然有少数读操作是从数据库读取。
- 读写分离,当有大量的读写操作时,将数据库进行读写分离是一个不错的选择,例如MySQL的主从热备份,通过相关配置可以将主数据库服务器的数据同步到从数据库服务器,实现数据库的读写分离,读写分离能够改善数据库的负载能力。
- 分区分库分表,将数据量较大的表水平或垂直切分,分散到不同的库或主机上,分散数据库的压力,提高性能。
- 应用拆分,将较重要或访问量较大的功能模块拆分出来作为新应用单独开发、运维。新应用与老应用间的相关依赖通过接口调用或其它方式交互。
集群有一定的处理高并发的能力,也能应对一定复杂的业务需求,改善了系统的性能,但是依然没有改变系统为单体架构的事实,此时存在的不足之处如下。
- 缺点:
- 并发容量虽有提高,但有限。虽做一定的应用拆分后,一定程度上可以缓解单体应用的问题。但随着服务拆分越来越多,开发、部署、运维、管理难度也越来越大。
- 持续交付能力差,业务越复杂,代码越多,修改代码和添加代码所需的时间越长。新人熟悉代码的时间长、成本高。
- 子应用间依赖耦合较紧,重复功能建设,重复代码等,服务间通信没有标准等。
微服务架构
“微服务”最初是由Martin Fowler 在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍
Martin Fowler是国际著名的OO专家,敏捷开发方法的创始人之一,现为ThoughtWorks公司的首
席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面,都是世界顶级的
专家,现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集
成的公司。早在20世纪80年代,Fowler就是使用对象技术构建多层企业应用的倡导者,他著有几
本经典书籍: 《企业应用架构模式》、《UML精粹》和《重构》等。
相对于大规模的集群,微服务带来了质的飞越,不仅仅是服务拆分,微服务是一整套的服务治理的架构,具备整套的设施。
微服务架构领域
- 特性:
- 每个服务为独立的业务开发,单独部署,跑在自己的进程中。
- 自动化测试、部署、运维( DevOps )。
- 快速演化、快速迭代。
- 整个业务由一系列的独立的服务共同组成系统。
- 高度容错性、高可用、高并发。
- 具备能力:
- 注册中心:应用启动自动注册,调用方自动发现上线应用。服务异常自动隔离。
- 配置中心:多环境配置管理,支持在线管理配置信息,客户端实时生效。支持版本管理,快速回滚。
- 消息中心:服务间异步通信的总线。
- 负载均衡:服务调用服务会采用一定的分发策略,一般是客户端分发策略。
- 服务间通信:使用http或RPC协议进行服务调用,REST、gRPC、Thrift、hession等
- 服务降级、熔断、重试:降级,服务或依赖服务异常时,返回保底数据。熔断,若依赖服务多次失效,则断开,不再尝试调用,直接返回降级值。重试,熔断后,定期探测依赖服务可用性,若恢复则恢复调用。
- 服务发布与回滚:红绿部署、灰度、AB Test等发布策略,可快速回滚应用。
- 服务动态伸缩、容器化:根据服务负载情况,可快速手动或自动进行节点增加和减少。
- 服务监控与告警:服务定期健康检察、指标统计、异常告警通知运维。
- 请求缓存与合并:服务间调用相同请求缓存,类似请求合并成批量请求,减少服务间通信,提高性能。
- 服务网关:用户请求过载时进行限流、排队,过载保护,黑白名单、异常用户过滤拦截等。
- 服务依赖、文档、Mock Server、版本管理:自动生成接口文档,接口版本化管理,Mock接口等。
- 日志收集、追踪、分析:集中收集各服务日志汇总,方便排障、问题调查、应用日志分析等。
- 性能监测APM:对各服务性能进行监测与分析,为服务优化提供数据支持。
以上我整理的微服务相关应具备的能力,内容相当的多,要搭建这样一套完善的微服务平台,花费的财力和时间都是巨大的。幸好开源界已经在各方面有众多的可选方案。
微服务架构挑战
- 服务规模大,部署、运维、管理难度大。
- 服务间调用关系复杂,调用链路长,排障难度大。
- 服务间通信成本变大,性能和容错带来的挑战。
- 服务间依赖较多,系统集成、测试难度变大。
- 开发人员技术能力挑战,各服务间重复代码,重复建设等。
- 集群规模大,功能性能监控、告警带来的挑战。
- 大规模分布式,数据一致性带来的挑战。
- 需求和版本协调复杂度大大增加,测试难度也增加。
- 对基础架构要求大大提高,规模大幅增加。
微服务实施
SpringCloud
SpringCloud是在SpringBoot基础之上构建的快速开发分布式系统(微服务)的工具集。
为开发人员提供了一个开箱即用,快速构建微服务的一些通用组件(例如配置管理,服务发现,断路器,智能路由,消息总线等)。
Dubbo
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的RPC实现服务的输出和输入功能,可以和Spring框架无缝集成。
下一代微服务Service Mesh(网格服务)
Service Mesh 架构图:
Service Mesh 开源项目简介:
- Linkerd(https://github.com/linkerd/li...):
第一代 Service Mesh,2016 年 1 月 15 日首发布,业界第一个 Service Mesh 项目,由 Buoyant 创业小公司开发(前 Twitter 工程师),2017 年 7 月 11 日,宣布和 Istio 集成,成为 Istio 的数据面板。
- Envoy(https://github.com/envoyproxy...):
第一代 Service Mesh,2016 年 9 月 13 日首发布,由 Matt Klein 个人开发(Lyft 工程师),之后默默发展,版本较稳定。
- Istio(https://github.com/istio/istio):
第二代 Service Mesh,2017 年 5 月 24 日首发布,由 Google、IBM 和 Lyft 联合开发,只支持 Kubernetes 平台,2017 年 11 月 30 日发布 0.3 版本,开始支持非 Kubernetes 平台,之后稳定的开发和发布。
- Conduit(https://github.com/runconduit...):
第二代 Service Mesh,2017 年 12 月 5 日首发布,由 Buoyant 公司开发(借鉴 Istio 整体架构,部分进行了优化),对抗 Istio 压力山大,也期待 Buoyant 公司的毅力。
- nginMesh(https://github.com/nginmesh/n...):
2017 年 9 月首发布,由 Nginx 开发,定位是作为 Istio 的服务代理,也就是替代 Envoy,思路跟 Linkerd 之前和 Istio 集成很相似,极度低调,GitHub 上的 star 也只有不到 100。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。