浅谈微服务及十二要素

微服务

微服务架构是各种因素影响下的产生的一种新的架构风格。

  1. 使用传统的单体式架构应用开发系统,如CRM、ERP等大型应用,随着新需求的不断增加,企业更新和修复大型单体式应用变得越来越困难。
  2. 随着移动互联网的发展,企业被迫将其应用迁移至流行的UI界面以便能兼容移动设备,这要求企业能实现应用功能的快速上线。
  3. 随着应用云化的日益普及,生于云端的应用具有与传统IT不同的技术基因和开发运维模式,云端的庞大计算计算能力及互联网公司大量开源轻量级技术不停涌现并日渐成熟。
  4. 新的方法与工具,如敏捷,运维开发一体化,极限编程的出现。
  5. 简化的基础设施如操作系统虚拟化,容器化,基础设施即服务(IaaS),服务平台化(PaaS),以及软件即服务(SaaS)的概念和应用的深入。

受到以上各种因素的影响,微服务架构应运而生

1.    微服务定义

微服务是一个抽象统称,在不同的语境里有不同的含义。在具体的交流中,可以分为微服务架构、微服务系统、API或消息。

1.1           微服务架构

微服务架构是在单体应用高复杂度、业务单元无法拆解的背景下,为了提升交付效率和加大系统的弹性,采用将多个可独立进行开发、管理、迭代的单一功能的模块组合出复杂的大型应用系统、各功能模块使用与编程语言无关的API集合相互通讯的方式的一种新的关于系统整体结构的抽象描述,用于指导大型系统各个方面的设计。

1.2           微服务系统

采用微服务架构思路设计的系统,我们称之为微服务系统。

1.3           微服务(API或消息)

我们更倾向于把提供特定的具体的功能的可以被外部调用的实现叫做API(Application Programming Interface)或者消息,比如Rest API、ActiveMQ或者RocketMQ等。

2      微服务标准(微服务十二要素)

2.1     基准代码

一份基准代码,多份部署,基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同,但每份部署可以使用其不同的版本。多个应用不可以共享同一份代码,可以将代码拆分独立的类库后通过依赖策略去加载。

2.2     显式依赖

通过依赖清单,明确的声明所有依赖项,在运行时,通过依赖隔离工具确保程序不会调用系统中存在却未声明的依赖项,开发环境与生产环境都应尊从。另外每个组件的依赖应该明确列出,由于多个组件存在相似的依赖,需要进行冗余依赖排除,减少版本冲突。

2.3     代码与配置分离

不建议将可配置的信息硬编码到程序中,可以存在在环境变量里,建议用配置中心存储各应用的配置,这样使用一套代码可以很方便的在不同环境上部署,启动时只需要指定配置环境,而不用改动任何代码,此配置应该与编程语言无关。

2.4     后端服务

把后端的服务当成资源。比如本地数据库,云数据库,消息服务,第三方服务,SMTP服务等,微服务系统不应区别对待本地还是第三方服务,不论使用本地服务还是使用云服务,通过URL或配置可以方便替换。禁止后端服务之间的耦合。

2.5     构建、发布、运行

严格的划分编译、发布、运行阶段,每个阶段由工具进行管理。持续集成,持续部署。如需修改运行的代码则需要重新进行构建、发布、运行三个环节,且顺序执行。三个环节可以手动执行,也可以自动执行。持续集成,持续发布一般在敏捷管理平台上进行管理。建议每个CI都只对应一套代码库。

2.6     无状态进程

应用必须为无状态应用,Session信息应该独立于应用存储,比如存储在Memcached或Redis中。需要持久化的数据应该存储于后端服务中,比如数据库mysql。在负载均衡策略上,由于应用的无状态性,所以要用轮询请求应用服务器的方式,以使各应用服务器的负载更加均衡。

2.7     数据隔离

建议只允许通过服务API 来访问服务的持久化数据,防止微服务之间隐式契约,确保微服务不能紧密耦合。不允许数据共享。微服务之间通过API或消息互相访问,也加大了微服务后台选型的灵活性,比如微服务后台数据库选型mysql还是oracle已经与服务调用者无关。

2.8     提升并发能力

进程优先于线程。通过横向扩展容器来提升吞吐能力,纵向扩展一般不推荐,比如增加内存,增加CPU核数,一般内存和CPU占用率过高都存在潜在的风险,需要优化程序逻辑。线程的使用要慎重,尽量减少线程的资源占用。

2.9     快速启动和优雅终止

在启动时应禁止自动执行的任务,及禁止同步加载大量数据,减少启动时间,这样有利于快速的对应用进行伸缩,快速响应配置和代码的变化。进程还应该在突然死亡时仍然保持健壮,比如重要数据要实时存储到后台。

2.10 开发与生产环境一致

缩小本地与线上差异,保证各环境的一致性,包括OS,容器规格,虚拟机规格,Tomcat版本,数据库版本,JDK版本,PaaS组件版本等,尽可能减少开发环境与生产环境的差异。

2.11 把日志当做事件流

应用应该把日志存储于日志云平台,不要自己存储在本地。要能够在终端看到应用的实时日志流,最好能够做到实时日志的聚合展示。通过日志要能够查询到每个服务的执行时间。

2.12 管理进程与其它应用进行使用同一份代码和配置

脚本,系统管理后台同样要用代码仓库管理,并且与应用代码保存在同一套代码库里,而且应该不受环境影响,要保证脚本可重复执行.

Leave a Reply