【关于分布式系统开发和微服务架构自我心得小记

一、一个完整项目为何要分布式开发?

完整项目业务实现是相当庞大,程序员在修改一个业务程序的的代码时,可能会影响整个项目的启动和部署,项目代码一个地方修改会产生很多问题,不利于程序的开发,同时项目的启动和部署是非常耗时,更不利于程序的运行。所以把一个项目拆成若各小项目块,单独修改,就能方便开发,在各个小板块之间,是通过网络来联系。一个单体应用拆分成多个服务,每个服务有自己独立的数据库。单个服务的复杂度降低。这就是微服务架构项目。

二、微服务架构是什么?

理论:微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务,我们仅做最低限度的集中管理。

分布式系统和微服务架构的关系。

微服务架构 是 分布式系统,分布式系统不一定是微服务架构;

比如 redis的中心化集群是分布是系统,但不是微服务;

应用系统当中,这两种的集群模式都有出现;

三、理解微服务中的分布式


怎样理解微服务中的分布式?举个招聘时某同学来面试的例子。A 同学说,目前所在公司在做从单应用到微服务架构迁移,已经差不多完成了。提到微服务感觉就有话题聊了,于是便问“是否可以简单描述下服务拆分后的部署结构、底层存储的拆分、迁移方案?”。于是 A 同学说,只是做了代码工程结构的拆分,还是原来的部署方式,数据库还是那个库,所有的微服务都用一个库,分布式事务处理方式是“避免”,尽量都同步调用……于是我就跟这位同学友好地微笑说再见了。

微服务的分布式不仅仅是容器应用层面的分布式,其为了高度自治,底层的存储体系也应该互相独立,并且也不是所有的微服务都需要持久化的存储服务。一个“手机验证码”微服务可能底层存储只用一个 Redis;一个“营销活动搭建页面”微服务可能底层存储只需要一个 MongoDB。

微服务中的分布式场景除了服务本身需要有服务发现、负载均衡,微服务依赖的底层存储也会有分布式的场景:为了高可用性和性能需要处理数据库的复制、分区,并且在存储的分库情况下,微服务需要能保证分布式事务的一致性。

 微服务优缺点

优点
单一职责原则;
每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定的业务功能或业务需求;
开发简单,开发效率高,一个服务可能就是专一的只干一件事;
微服务能够被小团队单独开发,这个团队只需2-5个开发人员组成;
微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的;
微服务能使用不同的语言开发;
易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如jenkins,Hudson,bamboo;
微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果,无需通过合作才能体现价值;微服务允许利用和融合最新技术;
微服务只是业务逻辑的代码,不会和HTML,CSS,或其他的界面混合;
每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库;

缺点
开发人员要处理分布式系统的复杂性;
多服务运维难度,随着服务的增加,运维的压力也在增大;
系统部署依赖问题;
服务间通信成本问题;
数据一致性问题;
系统集成测试问题;
性能和监控问题;

四、CAP原理介绍

C:Consistency  

即一致性,访问所有的节点得到的数据应该是一样的。注意,这里的一致性指的是强一致性,也就是数据更新完,访问任何节点看到的数据完全一致,要和弱一致性,最终一致性区分开来。

强一致性:在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于访问任一节点得到的都是最新的数据副本)

A:Availability

即可用性,所有的节点都保持高可用性。注意,这里的高可用还包括不能出现延迟,比如如果节点B由于等待数据同步而阻塞请求,那么节点B就不满足高可用性。

也就是说,任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

P:Partiton tolerance

即分区容忍性,这里的分区是指网络意义上的分区。由于网络是不可靠的,所有节点之间很可能出现无法通讯的情况,在节点不能通信时,要保证系统可以继续正常服务。

以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。此时有两个解决方案

一是暂停或关闭所有节点,等待网络恢复,数据达成一致,这样保证了数据一致性。

另一个是继续提供服务,保证可用性,那么访问S1和访问S2、S3得到的将会不同的数据,不满足一致性

无论使用哪一种方案,都无法保证CAP同时成立

CAP原理说,一个数据分布式系统不可能同时满足C和A和P这3个条件。所以系统架构师在设计系统时,不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。由于网络的不可靠性质,大多数开源的分布式系统都会实现P,也就是分区容忍性,之后在C和A中做抉择。

对CAP原理的一些常见的理解误区
看到网上很多文章说CAP原理是分布式系统的基石,但是CAP原理其实是对分布式数据存储系统的一个定论。我们假设一个分布式系统各个节点都读写同一个mysql实例,那么对于这个分布式系统来说,讨论CAP原理是没有意义的。因为各个节点之间可以不用因为数据复制而进行通信,满足分区容忍性(P),可以随时响应请求,满足可用性(A),同时因为访问的是一个数据库实例,本身已经保证了数据一致性(C)。

五、当CAP要求严格,实际开发中没不要这么强一致性时,我们就是选择弱一致性,采用BASE原理。

Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)

在分布式系统设计中引入柔性因素,降低设计和实现的难度,但又不影响基本使用

设计上的妥协和折中

Basically Available(基本可用)

算作完全可用和完全不可用中的一种折中,互联网上的应用,如果是完全不可用的,那这个系统就没存在必要了;而在互联网上,用户量等有时候难以预见,就造成了用户超出系统设计的标准,想一直保持完全可用就很难,所以折中下,我们可以通过延迟响应,流量削峰等手段来保障系统的核心功能的正常,从而实现基本可用。

Eventually consistent(最终一致性)

我们希望获取的数据就是正确的,这像一句废话,如果获取到的数据是不确定正确与否,那我们拿这些错误的数据干嘛。但是由于这样那样的问题,我们不能随时都保障数据的一致,所以我们有了数据的中间状态,即软状态,经过一定时间后,数据最终回归于最终一致,这些短暂的数据不一致性,对用户的影响很小,比如你更新一条微博动态,可能有的地方用户可以看到你这条微博消息,另外的用户看不到这条微博消息,这个影响不大,只要最终所有用户都可以看到你这条微博消息就可以了。

最终一致性的系统不承诺写入数据成功后,立刻就从系统中读出最新的数据,也不承诺具体多久之后可以读到最新的数据,而是尽可能保障特定时间级别之后的数据可用,这取决于很多因素,比如网络快慢,比如副本的多少等。如果我们设置过DNS域名就知道,DNS域名我们配置A记录后,域名和IP的关系不是立刻生效的,过多久也不好说,这就是个最新一致性的系统。

Soft state(软状态)

软状态故名思意就是可以变动的状态,强调的是数据状态处于一种临界状态。相对于软状态,就是硬状态,就是数据的状态是确定的。对于满足ACID的数据状态是硬状态。最终一致性的系统中,数据的读出来的不一定是最新的,我理解就是一种软状态即一种短暂的临时状态。

六、Spring Cloud 是什么?

Spring Cloud 是一系列框架的有序集合,它利用 Spring Boot 的开发便利性简化了分布式系统的开发,比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子,而是将市面上开发得比较好的模块集成进去,进行封装,从而减少了各模块的开发成本。换句话说:Spring Cloud 提供了构建分布式系统所需的“全家桶”。

Spring Cloud 现状
目前,国内使用 Spring Cloud 技术的公司并不多见,不是因为 Spring Cloud 不好,主要原因有以下几点:

Spring Cloud 中文文档较少,出现问题网上没有太多的解决方案。
国内创业型公司技术老大大多是阿里系员工,而阿里系多采用 Dubbo 来构建微服务架构。
大型公司基本都有自己的分布式解决方案,而中小型公司的架构很多用不上微服务,所以没有采用 Spring Cloud 的必要性。
但是,微服务架构是一个趋势,而 Spring Cloud 是微服务解决方案的佼佼者,这也是作者写本系列课程的意义所在。

Spring Cloud 优缺点
其主要优点有:

集大成者,Spring Cloud 包含了微服务架构的方方面面。
约定优于配置,基于注解,没有配置文件。
轻量级组件,Spring Cloud 整合的组件大多比较轻量级,且都是各自领域的佼佼者。
开发简便,Spring Cloud 对各个组件进行了大量的封装,从而简化了开发。
开发灵活,Spring Cloud 的组件都是解耦的,开发人员可以灵活按需选择组件。
接下来,我们看下它的缺点:

项目结构复杂,每一个组件或者每一个服务都需要创建一个项目。
部署门槛高,项目部署需要配合 Docker 等容器技术进行集群部署,而要想深入了解 Docker,学习成本高。
Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说,学习 Spring Cloud 是一个不错的选择。


七、为什么选择SpringCloud作为微服务架构

选型依据
整体解决方案和框架成熟度
社区热度
可维护性
微服务架构工具集,提供了搭建微服务架构所需用的各种工具,借由这些工具,开发人员可以快速的搭建一个微服务架构。

Spring Cloud 为开发者提供了工具来快速构建分布式系统中的一些常见模式(例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话,集群状态)。分布式系统协调存在一些通用模式,使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地工作,包括开发人员自己的笔记本电脑、裸机数据中心以及 Cloud Foundry 等托管平台。

八、 SpringCloud和SpringBoot的关系

SpringBoot专注于开苏方便的开发单个个体微服务;
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务,整合并管理起来,为各个微服务之间提供:配置管理、服务发现、断路器、路由、为代理、事件总栈、全局锁、决策竞选、分布式会话等等集成服务;
SpringBoot可以离开SpringCloud独立使用,开发项目,但SpringCloud离不开SpringBoot,属于依赖关系;
SpringBoot专注于快速、方便的开发单个个体微服务,SpringCloud关注全局的服务治理框架。


 

  • 0
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 0
    评论
©️2022 CSDN 皮肤主题:1024 设计师:我叫白小胖 返回首页
评论

打赏作者

qindalele

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值