Category - 微服务架构演进

2020-04-20 15:15:25    7    0    0

我们都知道docker是一个容器化工具, 那么什么是容器化, 容器化又给我们带来什么好处呢?

复杂的环境依赖

软件开发中经常遇到的一段对话就是"在我的机器上是好使的,怎么部署到别的环境就出问题了呢?".

软件的正常运行依赖各种各样的外部环境, 比如java程序依赖于所运行系统的环境变量、用户自定义的变量、本地文件系统、classpath、java_home等等,并且在ide中部分ide会隐式设置部分运行环境,造成开发-部署-维护等的环境不一样. 这通常需要花费大把的时间去排查和定位问题.

而一个可用的软件交付过程通常包括两个部分-开发和维护. 不幸的是, 我们很难保证开发阶段和维护阶段应用软件在一模一样的环境下运维. 要是有一个工具能保证开发和维护阶段应用所运行的环境, 那毕竟是开发和运维这的福音, 而容器化最初正是为了解决这一问题而设计的.

虚拟机和容器

虚拟机

容器化之前我们想要达到环境的隔离,常用的手段是使用精心配置的虚拟机镜像来打包应用进行部署, 以此来保证环境一致和资源隔离. 然而虚拟机在硬件层之上做了完整的虚拟化,庞大的操作系统带来了大量的系统资源开销,是得应用的部署成本大大提升.

title

容器

容器拥有虚拟机类等的环境隔离型, 同时多个容器共享操作系统之上命名空间, 如网络命名空间、IPC命名空间等, 以避免虚拟的操作系统资源开销.

容器非常轻量级, 在安装包大小和启动速度上都是虚拟机无法比拟的,

title

docker架构

Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化. 容器是完全使用沙箱机制,相互之间不会有任何接口.

title

docker的交互是典型的cs模式, docker client客户端负责接收命令并和docker daemon交互, docker daemon负责镜像的构建和管理、容器的启停、资源的维护

docker拉取和推送镜像要和镜像仓库通信, 默认使用docker hub作为镜像仓库,大部分公司都拥有自己的私有仓库,可以使用自定义镜像仓库进行镜像的维护.

2020-04-12 12:11:10    5    0    0

随着业务的不断发展, 用户体量的快速扩张. 从单体/垂直架构转移到分布式/微服务架构是自然而然的选择.

分布式理论

分布式理论是分布式系统的基础, 在任何情况下分布式系统都要满足网络分区容错性, 因此分布式系统都是在可用性和一致性方面做平衡.

CAP理论

CAP理论指的是在一个分布式系统中,一致性、 可用性、分区容错性、在任何情况下只能满足其中两个,三个不能同时满足.

三个特性含义如下:

  • Consistency(一致性) 指数据在多个副本之间能够保持一致的特性(严格的一致性)
  • Availability(可用性) 指系统提供的服务必须一直处于可用的状态,每次请求都能获取到非错的响应(不保证获取的数据为最新数据)
  • Partition tolerance(分区容错性) 分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环- 境都发生了故障

CAP原理告诉我们,C,A,P三个方面同时只能满足两个,不可能同时满足。然而对于分布式系统而言,分区容错性[P]是基本要求,系统根据自身方面的要求需要对可用性和一致性做取舍.

对于网站服务来说, 可用性可能价值更高, 所以一般网站都会选择作为可用性放弃一致性. 而对于数据库系统, 数据一致性是重中之重, 所以数据库系统追求的是一致性放弃的是可用性.

BASE理论

BASE的核心思想是:

既然无法做到强一致性,然而每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。

BASE理论的三个要点为:

  • 基本可用(Basically Available)
  • 软状态(Soft State)
  • 最终一致性(Eventually Consistent)

    1. 基本可用
      当系统出现故障时,损失部分功能的前提下保障系统基本功能的可用性.
      相比较正常的系统而言, 可能是响应时间的增大, 亦或者是功能的降级, 如电商系统大促秒杀期间为保障系统稳定导致部分服务接口降级.
    2. 软状态
      软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。
      相对于原子性的强一致硬状态而言,我们称之
2020-03-28 08:02:45    2    0    0

单体架构比较初级,典型的三级架构:数据层、业务逻辑层、展示层.

其架构图如下所示:


title

分层开发模式

单体应用一般采用水平分层MVC的开发模式. 标准的mvc模式将整个应用分成 Model、View 和 Controller 三个部分,而这些组成部分其实也有着几乎完全不同的职责。

  • 视图(V):管理作为位图展示到屏幕上的图形和文字输出;
  • 控制器(C):翻译用户的输入并依照用户的输入操作模型和视图;
  • 模型(M):管理应用的行为和数据,响应数据请求(经常来自视图)和更新状态的指令(经常来自控制器);

分层开发能有效提高系统的维护性,解决容错性问题

展示层

展示层也叫用户前端,是整个应用面向用户的入口,用户通过展示层与系统的交互.展示层为用户提供系统功能的操作、系统数据的展现.展现层按照面向的用户类型提供不同的交互服务.

例如在业务场景中,用户有普通用户、管理层用户、决策层用户.针对不同层级的用户,系统所提供的功能是不相同.

业务层

业务层是应用为解决业务需求,按照产品架构中的功能模块进行细化。业务层是对将产品层从粗到细的分解过程。这个过程是对业务的细化过程,把项目要交付的模块细分到最基本的单元。最基本单元是实现日常业务操作的最细粒度的功能点。由此,我们能够得到实现业务逻辑的全功能结构。

数据层

数据层按照应用的数据模型分别进行存储。这里的存储介质包含关系型数据库、NoSQL、分布式文件系统。

优缺点

单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。

优点

  • 易于开发:项目不需要复杂的技术栈,往往一套熟悉的技术栈就可以完成开发,前期开发的成本低,周期短,小型企业首选
  • 易于测试:因为不需要依赖其他接口,测试可以节约相当多时间了。
  • 易于部署:由于是完整的结构体,可以直接部署在一份服务器上即可

缺点

  • 复杂性高: 项目发展后期整个项目可能包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱
2020-03-10 08:02:02    24    0    0

服务架构的发展一般是随着创业团队的发展而变化的,随着团队的壮大分工的明细,服务架构也相应的由简单到复杂;在适当的时期选择合适的架构可以让事情变得事半功倍。

在从0到1搭建服务体系时的我们的探索历程如下:


title

单体架构

在团队初创时期,单体架构是自然而然的选择。这种架构模式开发部署快捷维护成本低,适合创业初期需求的快速变更和快速适错。

单体架构结构如下图:


title
单体架构

单体架构的显著特点是业务的所有功能融合在一个单体服务中, 所有功能存放在一个代码仓库中,开发人员开发维护一个代码仓库,功能上线要么同时部署同时回滚,适合小型团队的快速开发。

不幸的是,单体架构有很大的局限性。

  1. 一个简单的应用随时间的推移不断变大,敏捷开发和部署举步维艰。
  2. 单体架构的另一个问题是服务可靠性,所有模块运行在一个进程中,一个问题可能会拖垮整个进程。
  3. 单体式应用使得采用新架构和语言非常困难。

垂直架构

当团队发展到一定规模,组织之间分工越来越精细化,产品业务线分散开来。此时单体架构限制了团队之间的协同效率,比如代码分支的维护、功能开发的协同,同时也限制也发版测试上线的机动性。此时最简单有效的方案就是将服务按照产品线拆分成子服务,子服务之间平行推进。

垂直架构的结构如下图:


title
垂直架构

垂直架构是在单体架构的基础上,按照业务线对服务功能进行垂直拆分。将原来一个大服务拆分多个功能上独立的子服务。子服务之间物理上相互独立互不影响,有自己的数据库、缓存系统、负载均衡等。

垂直架构模式解决了业务团队产品线之间代码维护混乱沟通协作的问题、以及不同产品线功能上线时相互影响的问题。

垂直架构虽然解决单体架构带来的问题,同时也引入了新问题,功能复用困难,不同服务之间存在着大量功能相似重复造轮子的情况。

分布式微服务架构

功能的复用通常分为几种手段:代码级的复用;组件级的复用;模块级的复用;架构级的复用。

在单体架构和垂直架构里,功能的复用一般使用代