资讯专栏INFORMATION COLUMN

微服务简介

darcrand / 2405人阅读

摘要:微服务简介微服务架构是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。每个微服务仅关注于完成一件任务并很好地完成该任务。服务异常自动隔离。微服务架构挑战服务规模大,部署运维管理难度大。

微服务简介

微服务架构(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。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/11895.html

相关文章

  • 【一】EdgeX Foundry边缘计算框架简介

    摘要:边缘计算框架简介服务层是一系列松耦合开源的微服务集合。处理北向应用发往南向设备的请求当然该服务还会处理框架内其他微服务发往南向设备的请求,如本地的分析服务。 EdgeX Foundry边缘计算框架简介 EdgeX Foundry服务层 EdgeX Foundry是一系列松耦合、开源的微服务集合。该微服务集合构成了四个微服务层及两个增强的基础系统服务,这四个微服务层包含了从物理域数据采集...

    young.li 评论0 收藏0
  • 【一】EdgeX Foundry边缘计算框架简介

    摘要:边缘计算框架简介服务层是一系列松耦合开源的微服务集合。处理北向应用发往南向设备的请求当然该服务还会处理框架内其他微服务发往南向设备的请求,如本地的分析服务。 EdgeX Foundry边缘计算框架简介 EdgeX Foundry服务层 EdgeX Foundry是一系列松耦合、开源的微服务集合。该微服务集合构成了四个微服务层及两个增强的基础系统服务,这四个微服务层包含了从物理域数据采集...

    yeyan1996 评论0 收藏0
  • JHipster技术简介

    摘要:本文简单介绍是什么,为什么用,怎么用。技术栈是什么是一个开发平台,用于生成,开发,部署和。实现需定制化源码。 本文简单介绍Jhipster是什么,为什么用Jhipster,怎么用Jhipster。 WHAT - 技术栈 JHipster是什么 JHipster是一个开发平台,用于生成,开发,部署Spring Boot + Angular/React Web Application和Sp...

    hightopo 评论0 收藏0
  • 统一认证 - Apereo CAS 简介

    摘要:在将臭未臭之前,我们赶紧把其中的统一认证这块过一下。的历史前面说了是耶鲁大学实验室的在年出的一个开源系统。这次我们先看看官网出的一幅图,这张图片介绍了的组成以及支持的各种协议,各种特性,不烦看看 为什么要做这个尝试? 微服之道,方兴未艾;农之来学者,盖已千者! 这句是从《陶山集·太学案问》瞎改出来的。意思就是微服务的架构理念还在不断地发展,现在整个啥都 言必出微服务,差点都到了 没学...

    zhunjiee 评论0 收藏0
  • [直播视频] 《Java 服务实践 - Spring Boot 系列》限时折扣

    摘要:作为微服务的基础设施之一,背靠强大的生态社区,支撑技术体系。微服务实践为系列讲座,专题直播节,时长高达小时,包括目前最流行技术,深入源码分析,授人以渔的方式,帮助初学者深入浅出地掌握,为高阶从业人员抛砖引玉。 简介 目前业界最流行的微服务架构正在或者已被各种规模的互联网公司广泛接受和认可,业已成为互联网开发人员必备技术。无论是互联网、云计算还是大数据,Java平台已成为全栈的生态体系,...

    Enlightenment 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<