目 录CONTENT

文章目录

微服务基础知识(1)

Eric
2022-02-16 / 0 评论 / 0 点赞 / 163 阅读 / 3,278 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-02-16,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

微服务基础知识

1 系统架构的演变

1.1 概述

  • 随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

1.2 单体应用架构

  • web应用程序发展的早期,大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

单体应用架构.png

  • 比如搭建一个电商系统:客户下订单,商品展示,用户管理。这种将所有功能度部署在一个web容器中运行的系统就叫做单体架构,目前也有人称为单体地狱。

  • 优点:

    • ① 所有的功能集成在一个项目工程中。
    • ② 项目架构简单,前期开发成本低,周期短,小型项目的首选。
  • 缺点:

    • ① 全部功能集成在一个工程中,对于大型项目不易开发、扩展和维护。
    • ② 系统性能只能通过扩展集群结点,成本高,有瓶颈。
    • ③ 技术栈受限。
    • ④ 代码耦合度很高。
    • ⑤ 容错性差,比如用户管理出问题了,整个系统全部出问题,牵一发而动全身。

1.3 垂直应用架构

  • 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互补相干的几个应用,以提高效率。

垂直应用架构.png

  • 优点:

    • ① 项目架构简单,前期开发成本低,周期daunt,小型项目的首选。
    • ② 通过垂直拆分,原来的单体项目不至于无线扩大。
    • ③ 不同的项目可采用不同的技术。
    • ④ 针对不同的子工程优化。
    • ⑤ 解决高并发问题。
    • ⑥ 方便水平扩展,容错性好(相对于单体架构来说的,比如上图中的商品管理出问题了,对CMS系统和后台管理系统来说没影响)。
  • 缺点:

    • ① 全部功能集成在一个工程中,对于大型项目不易开发、扩展和维护。
    • ② 系统性能扩展只能通过扩展集群结点,成本高,有瓶颈。
    • ③ 系统间相互独立,会产生session共享问题(可以使用Redis Cluster、SpringSession等技术解决)。
    • ④ 重复的开发工作(比如上图中的用户管理功能在电商系统和后台管理系统中都有)。

1.4 分布式SOA架构

1.4.1 什么是SOA?

  • SOA,全称是Service-Oriented Architecture,即面向服务的架构。它可以根据需要通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

  • 站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目的是把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。

  • 通过上面的描述可以发现SOA有如下的特点:分布式、可重用、扩展灵活、松耦合。

1.4.2 SOA架构

  • 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使得前端应用能够更快速的响应多变的市场需求。

分布式SOA架构.png

  • 优点:

    • ① 抽取公共的功能为服务,提高开发效率。
    • ② 对不同的服务进行集群化部署解决系统压力。
    • ③ 基于ESB或Dubbo减少系统耦合。
  • 缺点:

    • ① 抽取服务的粒度较大。
    • ② 服务提供方和调用方接口耦合度较高。

1.5 微服务架构

微服务架构.png

  • 优点:

    • ① 通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将会缩短,运维成本也将大幅度下降。
    • ② 微服务遵循单一原则。微服务之间采用RESTful等轻量级协议传输。
  • 缺点:

    • ① 微服务过多,服务治理成本高,不利于系统维护。
    • ② 分布式系统开发的技术成本高(容错、分布式事务等)。

1.6 SOA和微服务的关系

  • SOA:面向服务的架构,是一种设计方法,其中包含多个服务,服务和服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统的进程之中。各个服务之间通过网络调用。

  • 微服务架构:其实和SOA架构类似,微服务是SOA架构上的升华,微服务架构强调的一个重点是"业务需要彻底的组件化和服务化",原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

功能SOA微服务
组件大小大块业务逻辑单独任务或小块业务逻辑
耦合通常松耦合总是松耦合
公司架构任何类型小型,专注于功能交叉团队
管理着重中央管理着重分散管理
目标确保应用能够交互操作执行新功能、快速拓展开发团队

2 分布式核心知识

2.1 分布式的远程调用

  • RESTful。

  • RPC。

2.2 分布式中的CAP原理

  • 现如今,对于大多数大型互联网应用,分布式系统正变得越来越重要。分布式系统最大的难点,就是各个节点的状态如何同步。CAP定理是这方面的基本定理,也是理解分布式系统的起点。

  • CAP理论有Eirc Brewer在ACM研讨会上提出的,而后CAP被奉为分布式领域的重要理论。分布式系统的CAP理论,首先把分布式系统中的三个特性进行了如下的归纳。

CAP.png

  • C(Consistency,一致性):数据一致更新,所有数据的变化都是同步的。

  • A(Availability,可用性):在集群中一部分节点故障后,集群整体是否还能有影响客户端的读写请求。

  • P(Partition tolerance,分区容错性):某个节点的故障,并不影响整个系统的运行。

一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上,那么出现分区之后,这一数据项就可能分布到各个区里。容忍性就提高了。

然而,要把数据复制到多个节点,就会带来一致性的问题,就是多个节点上面的数据可能是不一致的。要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。

总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。

作者:邬江
链接:https://www.zhihu.com/question/54105974/answer/139037688
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

选择说明
CA放弃分区容错性,加强一致性和可用性,其实就是传统的关系型数据库的选择
AP放弃一致性(强一致性),追求分区容错性和可用性,这时很多分布式系统设计时的选择,比如很多NoSQL数据库就是如此
CP放弃可用性,追求一致性和分区容错性,基本不会选择,网络问题会直接让整个系统不可用,比如zookeeper就是CP
  • 需要明确一点的是,在一个分布式系统当中,分区容错性和可用性是最基本的需求,所以在分布式系统中,我们的系统最应该关注的是AP,通过补偿机制寻求数据的一致性。

3 常见微服务框架

3.1 SpringCloud

  • SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发,如服务发现注册配置中心消息中线负载均衡熔断器数据监控等,都可以用SpringBoot的开发风格做到一键启动和部署。SpringCloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考研的服务框架组合起来,通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

3.2 Apache的ServiceComb

  • Apache ServiceCombo是业界第一个Apache微服务顶级项目,是一个开源微服务解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云,并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案,融合SDK框架级、零入侵ServerMesh场景并支持多种语言。

3.3 ZeroC ICE

  • Zeroc ICE是Zeroc公司的杰作,继承了CORBA的血统,是新一代的面向对象的分布式系统中间件。作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能和分布式能力。
0

评论区