93
回答
高手问答第 205 期 —— 资深架构师带来的微服务架构实战分享
开发十年,就只剩下这套Java开发体系了   

OSCHINA 本期高手问答(2018 年 7 月 18 日 — 7 月 24 日)我们请来了@cloudskyme  张锋为大家解答关于微服务架构方面的问题。

张锋,《微服务架构实战》一书作者,北京航空航天大学软件工程硕士,资深架构师,有10多年管理和架构经验,在业界颇具威望和影响力。曾就职于神州数据、亚信科技、中文在线及多家互联网公司,担任架构师及技术总监等职位,现在就职于中青旅,任架构组组长,成功管理和指导过三农综合服务信息平台、西北企业云服务平台、省级电信平台及多个互联网平台的架构升级改造。拥有工信部认证高级信息系统项目管理师资格。

从分布式服务到SOA,再到微服务,服务化的脚步一直在不断地前进。正所谓“分久必合,合久必分”,在企业高速发展的今天,单体架构已经很难适应业务的快速变化,微服务的出现,为应对快速变化的业务需求、冗长的开发周期提供了一种新的解决方案。它以模块化的思维应对快速变化的业务需求,使用比如自动化部署、自动化业务监控预警、调用链监控、容器化,以及快速开发等思想加快软件的开发周期,实现更快速、更高质量的交付,整体提高客户的满意度。

本期问答内容

1.微服务与传统架构的区别?
2.微服务的设计原则都有哪些?
3.Spring Boot 适合做微服务吗?为什么?
4.常用的微服务框架包括哪些?
5.微服务中 Docker 起到什么作用,与传统的虚拟化的区别是什么?
6.微服务如何做质量管理?
7.常用的 APM 监控工具包括哪些?
8.微服务之间通讯方式除了 RPC 还有哪些?

或者其它关于微服务架构相关问题,也欢迎大家积极提问!

为了鼓励踊跃提问,@博文视点  会在问答结束后从提问者中抽取 5 名幸运会员赠予《微服务架构实战》一书。

购买链接:天猫

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就微服务架构相关问题向@cloudskyme  张锋提问,请直接回帖提问。

举报
局长
发帖于3个月前 93回/6K+阅
共有93个答案 最后回答: 2个月前

引用来自“playhalo”的评论

你好,想请教一下,关于微服务架构service mesh,它比起传统的微服务架构有那些优势的地方?

Service mesh被用来处理服务间通讯的专用基础设施层,通过复杂的拓扑结构让请求传递的过程变得更可靠。

Service mesh通常作为一组轻量级高性能网络代理,这些代理和程序代码部署在一起,但是应用程序不需要对代理有任何动作。

Service mesh是一个网络模型,它是位于TCP/IP之上的抽象层。它假定底层的L3/L4网络是真实存在的,并且能够点对点地传递字节。

但与TCP不同的是,Service mesh具有更高的性能。

Service mesh最终并不是引入一项新功能,而是功能定位的转变。Web应用程序总是必须管理服务间通信的复杂性。

你可以思考下2000年的中型web应用程序的典型架构: 三层应用程序。 在这个模型中,应用程序逻辑、web服务逻辑和存储逻辑都是单独的一层。 层之间的通信虽然复杂,但这种复杂性是限定在一定范围内,因为毕竟只有两个跳转。这里没有“网格”,但是在每个层的代码中处理的跳转之间有通信逻辑。

当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时,它就开始崩溃了。 像Google、Netflix和Twitter这样的公司无时无刻都面临着巨大的流量需求,它们实现了云原生方案的前身: 应用层被分解成许多服务(有时称为“微服务”),层级间则形成了一个拓扑结构。 在这些系统中,广义的通讯层突然变得相关起来, 但通常以“胖客户端”的库集(library)形式出现, 比如twitter的Finagle,Netflix的Hystrix,以及Google的Stubby就是这样的例子。

从很多方面上来讲,像Finagle, Stubby和Hystrix这些库集其实是Service mesh的雏形。虽然它们受其周围环境的细节影响,并且需要使用特定的语言和框架,但是它们是用于管理服务到服务间通信的专用基础设施,并且(在开源Finagle和 Hystrix库集的情形下)可以在其公司之外使用。

到了云原生应用时期, 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素:容器(例如Docker),它提供了资源隔离和依赖关系管理,以及一个编排层(例如Kubernetes),它将底层硬件抽象出了一个同质池。

这三个组件支持应用程序在负载下可弹性伸缩的自然机制, 并能够处理云平台环境中存在的部分故障。

但面对数百个服务或数千个实例,和随时在重新安排实例的编排层,单个请求经由服务拓扑的路径可能非常复杂, 而由于容器使每个服务用不同的语言写入处理变得更容易了,库集方法也就不再可行了。

这种复杂性和关键性的结合,激发了对服务到服务间通信的专用基础层的需求,这个专用层与应用程序代码分离出来,并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为Service mesh。

引用来自“jasonwu24”的评论

@cloudskyme 您好,诚然,微服务给我们带来了诸多好处,但是微服务应用是分布式系统,由此必然会带来固有的复杂性,与单体应用比微服务技术显得更复杂一些。测试一个基于微服务架构的应用也是很复杂的任务。采用Spring Boot架构,对一个单体式web应用,测试它的REST API,是很容易的事情。反过来,同样的服务测试需要启动和它有关的所有服务(至少需要这些服务的stubs)。所以不能低估了采用微服务架构带来的复杂性。有什么好的有效的方式减少这些复杂性呢?另外,使用docker和k8s等容器技术是不是微服务架构体系的标配?一个成熟稳定的微服务架构体系是不是不能不使用docker和k8s?谢谢!

复杂性是必然的,不能随便切分服务,因为每增加一层,就增加一层复杂度

docker的话应该说是标配,k8s现在是docker官方的标配,使用不使用这个需要看团队的熟悉及掌握情况

docker是提高了资源的利用率,降低了部署的复杂性,使开发 测试 线上环境能够保持一致

--- 共有 2 条评论 ---
cloudskyme是的,CAP要根据业务场景,不可能同时满足。 3个月前 回复
tuo_另外一个关于微服务的挑战是分区的数据库架构。交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易,因为只有一个数据库。在微服务架构应用中,需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择,不仅仅是因为CAP理论,还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法,从而对开发者提出了更高的要求 3个月前 回复

引用来自“无限的瑕想”的评论

@cloudskyme ,您好,

我是来自于一家中小企业的运维和开发人员,一直很微服务很感兴趣,如果我们企业将来打算采用微服务的架构,我们将面临着哪些挑战?给不能给我们一些建议?

面临着哪些挑战?

1、思想的转变。首先要理解什么是微服务。

2、新技术以及新框架的学习。比如spring boot、docker等。

给不能给我们一些建议?

1、本书的第一章讲解了传统的架构和微服务架构的区别以及演变流程,可以首先有一个概念性的了解。

2、可以先让一部分人使用并且深入,然后在整体推广。

引用来自“Rwing”的评论

@cloudskyme 我想请问一下,微服务的粒度到底怎么划分,有什么经验吗

这个也是个设计问题,首先是业务必须熟悉,然后可以根据领域模型进行领域划分,拆分可以根据AKF扩展立方体(Scalability Cube),

这个立方体有三个轴线,每个轴线描述扩展性的一个维度,他们分别是产品、流程和团队:

X轴 —— 代表无差别的克隆服务和数据,工作可以很均匀的分散在不同的服务实例上;

Y轴 —— 关注应用中职责的划分,比如数据类型,交易执行类型的划分;

Z轴 —— 关注服务和数据的优先级划分,如分地域划分。


微服务的4个设计原则和19个解决方案

三个维度扩展的对比

通过这三个维度上的扩展,可以快速提高产品的扩展能力,适应不同场景下产品的快速增长。不同维度上的扩展,有着不同的优缺点:

1.X轴扩展

优点:成本最低,实施简单;

缺点:受指令集多少和数据集大小的约束。当单个产品或应用过大时,服务响应变慢,无法通过X轴的水平扩展提高速度;

场景:发展初期,业务复杂度低,需要增加系统容量。

2.Y轴扩展

优点:可以解决指令集和数据集的约束,解决代码复杂度问题,可以实现隔离故障,可以提高响应时间,可以使团队聚焦更利于团队成长;

缺点:成本相对较高;

场景:业务复杂,数据量大,代码耦合度高,团队规模大。

3.Z轴扩展

优点:能解决数据集的约束,降低故障风险,实现渐进交付,可以带来最大的扩展性。

缺点:成本最昂贵,且不一定能解决指令集的问题;

场景:用户指数级快速增长。

如何将理论付诸实践?

1.为扩展分割应用

X轴:从单体系统或服务,水平克隆出许多系统,通过负载均衡平均分配请求;

Y轴 :面向服务分割,基于功能或者服务分割,例如电商网站可以将登陆、搜索、下单等服务进行Y轴的拆分,每一组服务再进行X轴的扩展;

Z轴 :面向查找分割,基于用户、请求或者数据分割,例如可以将不同产品的SKU分到不同的搜索服务,可以将用户哈希到不同的服务等。

2.为扩展分割数据库 

X轴:从单库,水平克隆为多个库上读,一个库写,通过数据库的自我复制实现,要允许一定的读写时延;

Y轴 :根据不同的信息类型,分割为不同的数据库,即分库,例如产品库,用户库等;

Z轴 :按照一定算法,进行分片,例如将搜索按照MapReduce的原理进行分片,把SKU的数据按照不同的哈希值进行分片存储,每个分片再进行X轴冗余。

3.为扩展而缓存

在理想情况下,处理大流量最好的方法是通过高速缓存来避免处理它。从架构层面看,我们能控制的主要有以下三个层次的缓存:

对象缓存:对象缓存用来存储应用的对象以供重复使用,一般在系统内部,通过使用应用缓存可以帮助数据库和应用层卸载负载。

应用缓存:应用缓存包括代理缓存和反向代理缓存,一个在用户端,一个在服务端,目标是提高性能或减少资源的使用量。

内容交付网络缓存:CDN的总原则是将内容推送到尽可能接近用户终端的地方,通过不同地区使用不同ISP的网关缓存,达到更快的响应时间和对源服务的更少请求。

4.为扩展而异步

同步改异步:同步调用,由于调用间的同步依赖关系,有可能会导致雪崩效应,出现一系列的连锁故障,进而导致整个系统出现问题,所以在进行系统设计时,要尽可能的考虑异步调用方式,邮件系统就是一个非常好的异步调用例子。

应用无状态:当进行AKF扩展立方体的任何一个轴上的扩展时,都要首先解决应用的状态问题,即会话的管理,可以通过避免、集中和分散的方式进行解决。

--- 共有 1 条评论 ---
Rwing谢谢老师 ,太厉害了 3个月前 回复

@cloudskyme 您好,请教一下,在基于Spring Cloud的微服务架构中,使用docker和k8s这些容器化技术能带来哪些方面的好处?对于中小规模的微服务架构中,是否有使用docker和k8s的必要性呢?谢谢。

引用来自“Li_Peng”的评论

@cloudskyme 您好,请教一下,在基于Spring Cloud的微服务架构中,使用docker和k8s这些容器化技术能带来哪些方面的好处?对于中小规模的微服务架构中,是否有使用docker和k8s的必要性呢?谢谢。

容器技术不是模仿硬件层次,而是 在Linux内核里使用cgroup和namespaces来打造轻便的、将近裸机速度的虚拟技术操作系统环境。因为不是虚拟化存储,所以容器技术不会管 底层存储或者文件系统,而是你放哪里,它操作哪里。

也就是说,它能更细粒度的控制linux,能够做到按需分配,我们企业级开发种经常面临的一个问题就是资源不足,而使用docker可以更加有效的利用资源。这个跟企业的规模个人感觉不是很大。

引用来自“两江总督噶礼”的评论

@cloudskyme 您好,我想问下在您10多年的职业生涯中,您对自己最满意的项目是哪个,它给你带来了哪些收获呢?

其实是接触服务化之后,涉及到微服务改造的项目,说收获吧,有效的提升了自己的架构能力,开阔了视野,从一个简单的CRUD码农晋升为架构级别,面对高并发以及大数据的挑战,有了应对的心得和体会。

顶部