<返回更多

阿里微服务布道师:详解微服务架构设计

2020-09-08    
加入收藏

微服务

软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

阿里微服务布道师:详解微服务架构设计

 

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。)

Monolithic架构

阿里微服务布道师:详解微服务架构设计

 


Monolithic比较适合小项目,优点是:

开发简单直接,集中式管理, 基本不会重复开发

功能都在本地,没有分布式的管理开销和调用开销。它的缺点也非常明显,特别对于互联网公司来说(不一一列举了):

开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断

代码维护难:代码功能耦合在一起,新人不知道何从下手

部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长

稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉

扩展性不够:无法满足高并发情况下的业务需求

微服务架构

微服务是指开发一个单个小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说,如果每个服务都要同时修改,那么它们就不是微服务,因为它们紧耦合在一起;如果你需要掌握一个服务太多的上下文场景使用条件,那么它就是一个有上下文边界的服务,这个定义来自DDD领域驱动设计。

相对于单体架构和SOA,它的主要特点是组件化、松耦合、自治、去中心化,体现在以下几个方面:

我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的:通过解耦我们所做的事情,分而治之以减少不必要的损耗,使得整个复杂的系统和组织能够快速的应对变化。

我们为什么采用微服务呢?

"让我们的系统尽可能快地响应变化" - Rebecca Parson

让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话,那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化,在同期出现了诸多轻量级开发方法(诸如 XP、Scrum);2001年敏捷宣言诞生,之后又出现了精益、看板等新的管理方式。如果说,这些是为了尽快的响应变化,在软件开发流程和实践方面提出的解决方案,那么微服务架构就是在软件技术和架构层面提出的应对之道。

阿里微服务布道师:详解微服务架构设计

 

 

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服务之间如何通信

阿里微服务布道师:详解微服务架构设计

 

 

一般同步调用比较简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP,更容易实现,更容易被接受,服务端实现技术也更灵活些,各个语言都能支持,同时能跨客户端,对客户端没有特殊的要 求,只要封装了HTTP的SDK就能调用,所以相对使用的广一些。RPC也有自己的优点,传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个 的开发规范和统一的服务框架时,他的开发效率优势更明显些。

就看各自的技术积累实际条件,自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能 保证调用方的服务体验,继续干自己该干的活,不至于被后台性能拖慢。

不过需要付出的代价是一致性的减弱,需要接受数据最终一致性;还有就是后台服务一般要 实现幂等性,因为消息发送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验);最后就是必须引入一个独立的broker,如 果公司内部没有技术积累,对broker分布式管理也是一个很大的挑战。

 

阿里微服务布道师:详解微服务架构设计

 

微服务优点

微服务架构的缺点

需要考虑的问题

阿里微服务布道师:详解微服务架构设计

 

API为什么很重要

•服务价值的精华体现
•可靠、可用、可读
•只有一次机会

阿里微服务布道师:详解微服务架构设计

 

实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上,其他的请求被转给到一组服务。

阿里微服务布道师:详解微服务架构设计

 

相比于提供普适的API,API网关根据不同的客户端开放不同的API。比如,Netflix API网关运行着客户端特定的适配器代码,会向客户端提供最适合其需求的API。

API网关也可以实现安全性,比如验证客户端是否被授权进行某请求。

设计要素

•Version
•RequstID
•Auth&Signature
•RateLimit
•Docs
•ErrorCode&Message

阿里微服务布道师:详解微服务架构设计

 

 

微服务治理

•按需伸缩
–部署与监控运维成本
•独立部署
–机器数量与部署成本
•业务独立
–服务依赖、治理,版本管理、事务处理
•技术多样性
–环境部署成本、约定成本

•运行状态治理
–监控、限流、SLA、LB、日志分析
•服务注册与发现
•部署
–快速、复制、扩容
–单机开发
•调用
–安全、容错、服务降级、调用延时

阿里微服务布道师:详解微服务架构设计

 


阿里微服务布道师:详解微服务架构设计

 

 

服务容错

当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为1 -> N扇出. 在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应(Cascading Failure),严重时可致整个网站瘫痪。

阿里微服务布道师:详解微服务架构设计

 

服务依赖

阿里微服务布道师:详解微服务架构设计

 

服务框架

  1. 服务注册、发现、负载均衡和健康检查,假定采用进程内LB方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。
  2. 监控日志,框架一方面要记录重要的框架层日志、metrics和调用链数据,还要将日志、metrics等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。
  3. REST/RPC和序列化,框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来,HTTP/REST是当前主流API暴露方式,在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出Ajax友好的JSON消息格式,而对无线设备上的Native App,框架支持输出性能高的Binary消息格式。
  4. 配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。
  5. 限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。
  6. 管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
  7. 统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。
  8. 安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。
  9. 文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

微服务系统底座

一个完整的微服务系统,它的底座最少要包含以下功能:

以下功能不是最小集的一部分,但也属于底座功能:

容器(Docker)与微服务

•容器够小
–解决微服务对机器数量的诉求
•容器独立
–解决多语言问题
•开发环境与生产环境相同
–单机开发、提升效率
•容器效率高
–省钱
•代码/image一体化
–可复用管理系统
•容器的横向与纵向扩容
–可复制
–可动态调节CPU与内存

容器(Docker)与微服务

•Image管理
•系统安全管理
•授权管理
•系统成熟度
•社区成熟度

开发方式影响

随着持续交付概念推广以及Docker容器普及,微服务将这两种理念和技术结合起来,形成新的微服务+API + 平台的开发模式,提出了容器化微服务的持续交付概念。
下图传统Monolithic的DevOps开发队伍方式:

阿里微服务布道师:详解微服务架构设计

 

这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理,而微服务架构引入以后,如下图:

阿里微服务布道师:详解微服务架构设计

 

微服务促进了DevOps方式的重组,将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍,以及一个大的整体的平台队伍负责运营管理,两者之间通过API交互,做到了松耦合隔绝。

阿里微服务布道师:详解微服务架构设计

 


阿里微服务布道师:详解微服务架构设计

 

微服务的实施是有一定的先决条件:基础的运维能力(如监控、快速配置、快速部署)需提前构建,否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践,通过代码来描述计算和网络基础设施的方法,使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器,服务器之间可以拥有更高的一致性,降低了在“我的环境工作,而你的环境不工作”的可能,也是为后续的发布策略和运维提供更好的支撑。

阿里微服务布道师:详解微服务架构设计

 

由于Docker引入,不同的微服务可以使用不同的技术架构,比如Node.js JAVA Ruby Python等等,这些单个的服务都可以独立完成交付生命周期,如下:

阿里微服务布道师:详解微服务架构设计

 

微服务案例

Netflix的微服务架构如下,着重全球分发 高可扩展性和可用性:

阿里微服务布道师:详解微服务架构设计

 

Twitter的微服务架构,注重高效的可扩展的数据中心:

阿里微服务布道师:详解微服务架构设计

 

希望对您系统架构,软件项目开发,运维管理,系统架构与研发管理体系, 信息安全, 企业信息化等有帮助

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍最近更新
更多资讯 >>>