用户您好!请先登录!

分类目录Microservice

微服务架构解耦设计详解

耦合性,是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。

模块间联系越多,其耦合性越强,同时表明其独立性越差。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。高内聚低耦合,是软件工程中的概念,是判断设计好坏的标准,主要是面向对象的设计,主要是看类的内聚性是否高,耦合度是否低。

SpringCloud和Dubbo都是现在比较成熟的微服务框架,如何使用两者构建搭建你的微服务系统呢?他们是如何将你的系统解耦的?

我仅用10步,就写出了全网最全的微服务架构详解

阅读更多

Spring Cloud Gateway 2.0

为什么很多人觉得spring cloud gateway难用?因为它的背后用的是webflux,涉及到响应式编程,而不是传统的过程式编程。

我们把背后的技术梳理一下,不难发现,这个晦涩的根源,就来自于project reactor,与spring项目并驾齐驱的,”面向未来”的响应式编程框架。

结果最后的代码,都长的和lambda一样。其背后的思想,是观察者模式和非阻塞杂交的产物,学习曲线相对陡峭

万字Spring Cloud Gateway2.0,面向未来的技术,了解一下?

阅读更多

白话微服务架构

微服务是什么?

微服务是一种细粒度(Fine-Grain)的SOA

或许在座的高朋了解过其概念。个人认为,与其说微服务是一种技术,不如将其定义为一种架构,而架构则是"技"的实现与"术"的策略相辅相成。
"术"的策略需要分析使用场景,进行合理地划分业务边界,实现"业以类聚",然而"技"的实现则通过特定的技术在实现业务逻辑之时,更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性,达到"技以群分"的目的。

由此而论,我个人偏好将其定义为:”微服务是一种细粒度的SOA”。

这样定义的好处在于,没必要去重复地”抹黑””单体应用”(Monolithic,也有人翻译成”巨石应用”),缘于SOA技术的衍化过程中早已提及。那么,细粒度更多的体现在”取其精华,去其糟粕”。

阅读更多

微服务不是银弹

大部分时候,微服务都是建立在一种基于请求和响应的协议之上。比如,REST等。这种方式是自然的。我们只需要调用另外一个模块就是了,然后等待响应返回,然后继续。这样的方式确实也满足了我们的很多的场景:用户通过点击页面的一个按钮然后希望发生一些事情。

但是,当我们开始接触许多独立的service的时候,事情就发生改变了。随着service数量急速的增长,同步交互比例也随着service在急速增长。这时候,我们的service就会遇到很多的瓶颈。

于是,不幸的ops工程师们就被我们坑了,他们疲惫的奔波于一个又一个的service,拼凑在一起的二手信息片段,谁说了什么,去往哪里,什么时候发生?等等。。。

这是一个非常典型的问题。市面上也有一些解决方案。一种方案就是确保您的个人服务具有比您的系统更高的SLA。 Google提供了这样做的协议。另一种方法是简单地分解将服务绑定在一起的同步关系。

阅读更多

微软开源微服务构建软件 Dapr

随着越来越多的开发人员构建可扩展的云原生应用,利用托管服务来部署和运行这些云原生应用。在过去几年中,这一转变值得人们关注。随着这一转变,微服务架构已经成为构建云原生应用的标准,预计到 2022 年,将有 90% 的新应用采用微服务架构。微服务架构提供了极具说服力的好处,包括可扩展性、松散的服务藕合和独立部署等,但这种方法的成本可能很高,因为开发人员需要了解和熟练掌握分布式系统。

开发人员希望专注于业务逻辑,频繁且增量地迁移遗留代码,同时依靠平台为他们的应用提供所需的规模、弹性、可维护性、灵活性和云原生架构的其他属性。然而,开发人员发现,在云端和边缘之间的可移植性有限,他们不断地解决相同的分布式系统问题,如状态管理、弹性方法调用和事件处理。此外,许多编程运行时通常具有狭隘的语言支持和严格控制的特性集,这使得构建微服务架构变得具有挑战性。

为了使所有开发人员能够使用任何语言和框架轻松地构建可移植的微服务应用,无论是编写新代码还是迁移现有代码,我们很高兴地宣布将 Dapr 开源。

阅读更多

Common Implementation of High Availability in Microservice Architecture

高可用并不是一套整体解决方案,而是由诸多环节组成,一环扣一环,最终串起来组成一个整个系统的高可用落地方案。

什么是高可用

在定义什么是高可用,可以先定义下什么是不可用,一个网站的内容最终呈现在用户面前需要经过若干个环节,而其中只要任何一个环节出现了故障,都可能导致网站页面不可访问,这个也就是网站不可用的情况。

参考维基百科,看看维基怎么定义高可用:

系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一。

这个难点或是重点在于“无中断”,要做到 7×24 小时无中断无异常的服务提供。

为什么需要高可用

一套对外提供服务的系统是需要硬件,软件相结合,但是我们的硬件总是会出故障,软件会有 Bug,硬件会慢慢老化,网络总是不稳定,软件会越来越复杂和庞大。

除了硬件软件在本质上无法做到“无中断”,外部环境也可能导致服务的中断,例如断电,地震,火灾,光纤被挖掘机挖断,这些影响的程度可能更大。

阅读更多

微服务框架设计实践

复杂业务开发过程中的痛点

  1. 时间紧、任务多、团队大、业务增⻓快,如何还能保证架构稳定可靠?
  2. 研发水平参差不其、项木压力自顾不暇,如何保证质量基线不被突破?
  3. 公司有各种⼯具平台、 SDK、最佳实践,如何尽可能的在业务中使用?
  4. 用什么“框架”可以解决问题?

从服务框架的演进历程中找到规律

标志性的服务框架

  • Web 服务框架: MVC 架构
  • ASP.Net(since 2002):传统 C/S 开发模式在 Web 上的应⽤
  • Ruby on Rails(since 2005): MVC 框架的巅峰, “约定⼤于配置”
  • Web 服务框架: SaaS 与 RESTful
  • Sinatra(since 2007):纯路由框架,诸多框架的灵感源泉
  • 微服务框架: RPC 服务
  • Thrift(since 2007):开源 IDL-based 框架的⿐祖
  • 微服务架构:容器化与 FaaS
  • Serverless(since 2015):基于云计算平台,回归框架本质
  • Istio(since 2018):专注于解决与业务无关的其它网络通信问题

阅读更多

网飞实践的微服务:更快、更小、更强

几年前的文章,即使现在回头审视,也依旧很有价值。

无论您是否听说过微服务,我敢肯定您听说过 Netflix。我甚至敢打赌您听说过 Netflix 开源软件 (NOSS),这得益于 Netflix 在创建和发布管理云基础架构的软件上取得的成功,它是为 Netflix 数字-娱乐-流媒体帝国提供强力支持的软件。

从大约 2009 年开始(完全由 API 推动且乘着我们所称的微服务的第一波浪潮),Netflix 完全重新定义了它的应用程序开发和操作模型。在那时,该公司被一些行业旁观者嘲笑 “你们疯了!” 或 “这可能适合 Netflix,但没有其他任何公司能这么做。”很快来到看 2013 年,大部分人的态度已转变为 “我们正在努力使用微服务”。525,000 多条的 Google 微服务 搜索结果,暗示该概念无疑既有效又强大。

阅读更多

Spring Cloud Alibaba GA且正式发布了

无论怎么看,Alibaba都是在向Netflix致敬,Spring Cloud终于在国内也有替代的正式的,且开源解决方案,作为产品簇从Apache孵化器毕业真是一件了不起的事。

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

依托 Spring Cloud Alibaba,您只需要添加一些注解和少量配置,就可以将 Spring Cloud 应用接入阿里微服务解决方案,通过阿里中间件来迅速搭建分布式应用系统。

阅读更多

一步步步入微服务的全景

要理解微服务,首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用,即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的,这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。

最初的需求

几年前,小明和小皮一起创业做网上超市。小明负责程序开发,小皮负责其他事宜。当时互联网还不发达,网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单,只需要一个网站挂在公网,用户能够在这个网站上浏览商品、购买商品;另外还需一个管理后台,可以管理商品、用户、以及订单数据。

我们整理一下功能清单:

  • 网站
  • 用户注册、登录功能
  • 商品展示
  • 下单
  • 管理后台
  • 用户管理
  • 商品管理
  • 订单管理

由于需求简单,小明左手右手一个慢动作,网站就做好了。管理后台出于安全考虑,不和网站做在一起,小明右手左手慢动作重播,管理网站也做好了。总体架构图如下:

微服务是每个程序员不得不过的坎:一文带你详解微服务架构

 

小明挥一挥手,找了家云服务部署上去,网站就上线了。上线后好评如潮,深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。

阅读更多

微软关于微服务体系结构的理解

微服务体系结构由一系列小型的自治服务组成。 每个服务都是自包含服务,并且应实现单个业务功能。

微软关于微服务体系结构的理解

在某些方面,微服务是面向服务的体系结构 (SOA) 的自然演变,但微服务与 SOA 之间也存在一些差异。 下面是微服务的一些典型特征:

  • 在微服务体系结构中,服务具有规模小、独立和松散耦合的特点。
  • 每个服务都是一个单独的基本代码,可由小型开发团队管理。
  • 服务可独立部署。 团队可以更新现有服务,而无需重新生成和重新部署整个应用程序。
  • 服务负责暂留自己的数据或外部状态。 这一点与传统模型不同,后者由单独的数据层处理数据暂留。
  • 服务通过定义完善的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。
  • 服务无需共享相同的技术堆栈、库或框架。

除了服务本身,典型微服务体系结构中还会出现其他组件:

阅读更多

微服务写的很全的一篇文章

今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。

1.什么是微服务

1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可)

2)独立的进程(java的tomcat,nodejs等)

3)轻量级的通信(不是soap,是http协议)

4)基于业务能力(类似用户服务,商品服务等等)

5)独立部署(迭代速度快)

6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择)

ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。

2. 怎么权衡微服务的利于弊

利:

强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活)

可独立部署。

技术多样性。

弊:

分布式复杂性。

最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题)

运维复杂性。

测试复杂性。

3. 企业在什么时候考虑引入微服务

从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的时候,业务简单,用单体服务反而生产力很高。随着公司的发展,业务复杂性慢慢提高,这时候就可以采用微服务来提升生产力了。至于这个转化的点,需要团队的架构师来进行各方面衡量,就个人经验而言,团队发展到百人以上,采用微服务就很有必要了。

有些架构师是具有微服务架构能力,所以设计系统时就直接设计成了微服务,而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法,因为一开始对业务领域并不是很了解,并且业务模式还没有得到验证,这时候上微服务风险比较高,很有可能失败。所以建议大家在单服务的应用成熟时,并且对业务领域比较熟悉的时候,如果发现单服务无法适应业务发展时,再考虑微服务的设计和架构。

4.微服务的组织架构

如上图左边,传统的企业中,团队是按职能划分的。开发一个项目时,会从不同的职能团队找人进行开发,开发完成后,再各自回到自己的职能团队,这种模式实践证明,效率还是比较低的。

如上图右边,围绕每个业务线或产品,按服务划分团队。团队成员从架构到运维,形成一个完整的闭环。一直围绕在产品周围,进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模,建议按照亚马逊的两个披萨原则,大概10人左右比较好。

5:怎么理解中台战略和微服务

中台战略的由来:马云2015年去欧洲的一家公司supersell参观,发现这个公司的创新能力非常强,团队的规模很小,但是开发效率很高。他们就是采用中台战略。马云感触很深,回国后就在集团内部推出了中台战略。

简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台,把前端的应用变得更小更灵活。当中台越强大,能力就越强,越能更好的快速响应前台的业务需求。打个比喻,就是土壤越肥沃,越适合生长不同的生物,打造好的生态系统。

6:服务分层

每个公司的服务分层都不相同,有的公司服务没有分层,有的怎分层很多。目前业界没有统一的标准。

下面推荐一个比较容易理解的两层结构。

1:基础服务: 比如一个电商网站,商品服务和订单服务就属于基础服务(核心领域服务)。缓存服务,监控服务,消息队列等也属于基础服务(公共服务)

2:聚合服务 :例如网关服务就算一种聚合服务(适配服务)。

这是一种逻辑划分,不是物理划分,实际设计的东西很多很复杂。

7:微服务的技术架构体系

下图是一个成型的互联网微服务的架构体系:

1:接入层 负载均衡作用,运维团队负责

2:网关层 反向路由,安全验证,限流等

3:业务服务层 基础服务和领域服务

4:支撑服务层

5:平台服务

6:基础设施层 运维团队负责。(或者阿里云)

8:微服务的服务发现的三种方式

第一种:如下图所示,传统的服务发现(大部分公司的做法)。服务上线后,通知运维,申请域名,配置路由。调用方通过dns域名解析,经过负载均衡路由,进行服务访问。缺点: LB的单点风险,服务穿透LB,性能也不是太好

第二种:也叫客户端发现方式。如下图所示。通过服务注册的方式,服务提供者先注册服务。消费者通过注册中心获取相应服务。

并且把LB的功能移动到了消费者的进程内,消费者根据自身路由去获取相应服务。优点是,没有了LB单点问题,也没有了LB的中间一跳,性能也比较好。但是这种方式有一个非常明显的缺点就是具有非常强的耦合性。针对不同的语言,每个服务的客户端都得实现一套服务发现的功能。

第三种:也叫服务端发现方式,如下图所示。和第二种很相似。但是LB功能独立进程单独部署,所以解决了客户端多语言开发的问题。唯一的缺点就是运维成比较高,每个节点都得部署一个LB的代理,例如nginx。

9.微服务网关

网关就好比一个公司的门卫。屏蔽内部细节,统一对外服务接口。

下图是一个网关所处位置的示例图。

10:Netflix Zuul网关介绍

核心就是一个servlet,通过filter机制实现的。主要分为三类过滤器:前置过滤器,过滤器和后置过滤器。

主要特色是,这些过滤器可以动态插拔,就是如果需要增加减少过滤器,可以不用重启,直接生效。原理就是:通过一个db维护过滤器(上图蓝色部分),如果增加过滤器,就将新过滤器编译完成后push到db中,有线程会定期扫描db,发现新的过滤器后,会上传到网关的相应文件目录下,并通知过滤器loader进行加载相应的过滤器。

整个网关调用的流程

上图从左变http Request开始经过三类过滤器,最终到最右边的Http Response,这就是Zull网关的整个调用流程。

11:微服务的路由发现体系

整个微服务的路由发现体系,一般由服务注册中心和网关两部分组成。以NetFlix为例子,Eureka和Zull这两个组件支撑了netFlix整个的路由发现体系。如下图所示,首先外部请求发送到网关,网关去服务注册中心获取相应的服务,进行调用。其次内部服务间的调用,也通过服务注册中心进行的

12.微服务配置中心

目前大部分公司都是把配置写到配置文件中,遇到修改配置的情况,成本很高。并且没有修改配置的记录,出问题很难追溯。配置中心就接解决了以上的问题。

可配置内容:数据库连接,业务参数等等

配置中心就是一个web服务,配置人员通过后台页面修改配置,各个服务就会得到新的配置参数。实现方式主要有两种,一种是push,另一种是pull。两张方式各有优缺点。push实时性较好,但是遇到网络抖动,会丢失消息。pull不会丢失消息但是实时性差一些。大家可以同时两种方式使用,实现一个比较好的效果。如下图所示,这是一个国内知名互联网公司的配置中心架构图。

开源地址:http://github.com/ctripcorp/appollo

13:RPC遇到了REST

内部一些核心服务,性能要求比较高的可以采用RPC,对外服务的一般可以采用rest。

14:服务框架和治理

微服务很多的时候,就需要有治理了。一个好的微服务框架一般分为以下14个部分。如下图所示。这就是开篇所说的,微服务涉及的东西很多,有些初创公司和业务不成熟的产品是不太适合的,成本比较高。

目前国内比较好的微服务框架就是阿里巴巴的DUBBO了,国外的就是spring cloud,大家可以去研究一下.

15:监控体系

监控是微服务治理的重要环节。一般分为以下四层。如下图所示。

监控的内容分为五个部分:日志监控,Metrics监控(服务调用情况),调用链监控,告警系统和健康检查。

日志监控,国内常用的就是ELK+KAFKA来实现。健康检查和Metrics,像spring boot会自带。Nagios也是一个很好的开源监控框架。

16:Trace调用链监控

调用链监控是用来追踪微服务之前依赖的路径和问题定位。例如阿里的鹰眼系统。主要原理就是子节点会记录父节点的id信息。

下图是目前比较流行的调用链监控框架。

17:微服务的限流熔断

假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务,继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高,则会导致调用A服务的请求被堵住,堵住的请求会消耗占用掉系统的线程、io等资源,当该类请求越来越多,占用的计算机资源越来越多的时候,会导致系统瓶颈出现,造成其他的请求同样不可用,最终导致业务系统崩溃。

一般情况对于服务依赖的保护主要有两种方式:熔断和限流。目前最流行的就是Hystrix的熔断框架。

下图是Hystrix的断路器原理图:

限流方式可以采用zuul的API限流方法。

18.Docker 容器部署技术&持续交付流水线

随着微服务的流行,容器技术也相应的被大家重视起来。容器技术主要解决了以下两个问题:

1:环境一致性问题。例如java的jar/war包部署会依赖于环境的问题(操着系统的版本,jdk版本问题)。

2:镜像部署问题。例如java,rubby,nodejs等等的发布系统是不一样的,每个环境都得很麻烦的部署一遍,采用docker镜像,就屏蔽了这类问题。

下图是Docker容器部署的一个完整过程。

更重要的是,拥有如此多服务的集群环境迁移、复制也非常轻松,只需选择好各服务对应的Docker服务镜像、配置好相互之间访问地址就能很快搭建出一份完全一样的新集群。

19.容器调度和发布体系

目前基于容器的调度平台有Kubernetes,mesos,omega。下图是mesos的一个简单架构示意图。

下图是一个完整的容器发布体系

Spring Cloud的几个组件的一些理解

一、SpringCloud和Dubbo的区别

  1. SpringCloud和Dubbo主要区别

SpringCloud和Dubbo都是现在主流的微服务架构。

SpringCloud是apache旗下的Spring体系下的微服务解决方案,Dubbo是用于治理阿里系的分布式服务框架。

讲道理,我跟喜欢Spring Cloud,Dubbo只治理自身,对于其他服务只能借助于第三方,没有一个完整健康的生态,而Spring Cloud除了自己还有其21个子项目,以后会更多,谁让人家的Spring家族呢!

在技术选型的时候,由于远程调用方式以及注册中心等原因,我们二者只能选其一。

阅读更多