为什么选择微服务
一般情况下,业务应用我们都会采用模块化的分层式架构,所有的业务逻辑代码最终会在一个代码库中并统一部署,我们称这种应用架构为单体应用。 单体应用的问题是,全部开发人员会共享一个代码库,不同模块的边界模糊,实现高内聚、松耦合极其困难。 肯定大家会碰到过这类场景,当尝试去重构改进代码时,改了一个地方好几个其他模块也需要同步改动, 当初划分的模块边界轻易被穿透,有人给这种应用的架构起了一个很形象的名字叫 “洋葱架构”。
Netflix是一家成功实践微服务架构的互联网公司,总结了一套行之有效的微服务方案。微服务架构强调 “微”,服务紧密围绕业务领域,形成高度内聚的自治性。
更多的单体应用和微服务优劣势请参看《微服务实战(一):微服务架构的优势与不足》。
微服务特征
业务能力建模:高内聚、松散耦合,暴露接口而隐藏实现细节
服务协作模型:中心化和去中心化
服务交互方式:RPC/REST等
自动化文化与环境:自动化构建、自动化测试、自动化部署
服务发布:灰度发布
服务部署:部署独立性、失败隔离性、可监控性;一服务一主机模型需要虚拟化、容器化
服务配置:中心化配置服务
服务流控:降级、限流
服务恢复:多考虑故障如何快速恢复服务而非如何避免故障发生
当前业界比较成熟的微服务框架有Netflix的Karyon/Ribbon,Spring的Spring Boot/Cloud,阿里的Dubbo等。
Netflix的微服务框架
Netflix是一家成功实践微服务架构的互联网公司,几年前,Netflix就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括:
Eureka:服务注册发现框架
Zuul:服务网关
Karyon:服务端框架
Ribbon:客户端框架
Hystrix: 服务容错组件
Archaius: 服务配置组件
Servo: Metrics组件
Blitz4j: 日志组件
微服务框架
1、服务注册、服务发现、健康检查
如果我们采用进程内LB方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。
2、RPC/REST和序列化
框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来,HTTP/REST是当前主流API暴露方式,在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出Ajax友好的JSON消息格式,而对无线设备上的Native App,框架支持输出性能高的Binary消息格式。
3、管理接口
框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。
4、安全控制
安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。
5、配置管理
除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。
6、监控日志
框架一方面要记录重要的框架层日志、服务调用链数据,还要将日志、调用链数据等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般由日志系统做进一步分析和处理。
7、统一错误处理
对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。
8、流控和容错
框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。
负载均衡
1、集中式的负载均衡方案
在服务消费者和服务提供者之间有一个独立的LB,LB通常是专门的硬件设备如F5,或者基于软件如LVS,HAproxy等实现。LB上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向LB发起请求,由LB以某种策略(比如Round-Robin)做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力,能自动摘除不健康的服务实例。
服务消费方如何发现LB呢?通常的做法是通过DNS,运维人员为服务配置一个DNS域名,这个域名指向LB。
方案优缺点:
1)、单点问题,所有服务调用流量都经过LB,当服务数量和调用量大的时候,LB容易成为瓶颈,且一旦LB发生故障对整个系统的影响是灾难性的。
2)、LB在服务消费方和服务提供方之间增加了一跳(hop),有一定性能开销。
2、进程内的负载均衡方案
进程内LB方案将LB的功能以库Library的形式集成到服务消费方进程里头,该方案也被称为软负载(Soft Load Balancing)或者客户端负载方案。这一方案需要一个服务注册表(Service Registry)配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的LB组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性(Availability)要求很高,一般采用能满足高可用分布式一致的组件(例如Zookeeper, Consul, Etcd等)来实现。
方案优缺点:
1)、是一种分布式方案,LB和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。
但由于该方案以客户库(Client Library)的方式集成到服务调用方进程里头,
2)、需要开发支持多种不同语言的客户端,有一定的研发成本。
3)、客户库Library跟随服务调用方发布到生产环境中,后续如果要对客户库Library进行升级,会有很大的维护成本。
阿里开源的服务框架Dubbo也是采用类似机制。
3、主机独立的负载均衡方案
主机独立LB进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将LB和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立LB进程做服务发现和负载均衡。
方案优缺点:
1)、是一种分布式方案,没有单点问题,一个LB进程挂了只影响该主机上的服务调用方,服务调用方和LB之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB的升级不需要服务调用方改代码。
2)、不足是部署较复杂,环节多,出错调试排查问题不方便。
服务前端路由
IDL+Nginx+AOP
微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关(Service Gateway)。
服务网关service Gateway
1、服务反向路由
2、安全认证和防爬虫
3、限流和容错
4、监控
5、日志
服务容错
当我们的业务逐渐复杂以后,服务之间的依赖关系也会有错综复杂,例如,一个前端请求一般会依赖于多个后端服务。由于,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应(Cascading Failure),严重时可致整个网站瘫痪。
我们可以从不同的纬度避免和解决:
服务设计:
1、基础服务
2、复杂业务服务
3、减少服务复杂的依赖,尽量保持简单的依赖关系
容错设计:
1、故障隔离、容错
2、降级、限流
3、快速失败(Fail Fast):直接抛出异常、可以返回空值或缺省值
(未完待续)