微服务应具备的12个属性

该文翻译自Pivotal公司的 Matt Stine大牛的书籍《Migrating to Cloud Native Application Architectures》。

“Twelve-Factor”应用程序是针对cloud-native应用程序架构的众多模式的一个集合,最初是由Heroku的工程师们提炼出来的。

这些模式描述了一个云原生的应用程序的原型。他们专注性能,安全性和扩展性,强调声明性配置,无状态/无共享的进程水平扩展,和总体松耦合的部署环境。云应用平台,如Cloud Foundry,Heroku和Amazon Elastic

Beanstalk针对部署十二因素应用程序进行了优化。

在这个十二个因素中,应用程序(application或app)指的是一个单独的可部署单元,a single deployable unit。组织通常指的是多个可部署单元的应用程序的集合。我们更愿意认为这些多个可部署的单元组成一个分布式系统。

一个 twelve-factor 应用程序应该遵循下列套路:

Codebase

每个可部署的应用程序被作为代码库来进行跟踪,同时这个代码库由版本控制系统进行跟踪。这个应用程序可能在多个环境中有很多个被部署的实例。

Dependencies

一个应用显式地声明以及隔离依赖,这些都是通过一些不错的工具来实现(比如, Maven,Bundler,NPM等等),而不是在部署环境中隐式的实现依赖。

Config

配置或者其他任何各个部署环境之间不同的内容(比如,development, stag、ing, production)都是通过操作系统级别的环境变量来注入的。

Backing services

后台负责支撑的那些services,比如数据库们或者消息系统的brokers们,都被看作是一些可以插挂的资源(attached resources),并且一视同仁的被所有的环境所存取和消费。

Build, release, run

构建一个可部署的应用程序构件的各个阶段,把这个构件和配置进行结合,然后基于这个“构件和配置”的结合体来启动一个或多个进程,这些进程是严格独立的和分离的。

Processes

应用程序被作为一个或多个无状态的进程(比如:master或者workers),这些进程之间没有任何共享的内容。任何需要的状态信息都由backing services来提供(比如cache,object store等等)。

Port binding

应用程序都是自成一体的,对外输出服务都是通过端口绑定(包括HTTP)

Concurrency

并发通常是通过水平扩展应用程序的进程来完成的(尽管进程们也可能内部管理多个线程来进行工作,如果有必要的话)

Disposability

健壮性被最大化的展现了出来。进程们可以被快速的启动以及优雅的关闭。这些方面使得我们可以快速而有弹性的扩展、快速而有弹性的真对更新进行部署以及快速而有弹性的从崩溃中恢复过来。

Dev/prod parity

dev和prod的公平性。持续集成和持续部署,也就是CI/CD,能够保证development, staging以及production各个环境尽可能的相似甚至一样。

Logs

不再去管理log文件,而是把日志们作为一种事件流(event streams),允许执行环境通过中央的服务( centralized services)来收集、聚合、索引以及分析这些事件。

Admin processes

task管理,如数据库迁移,都可以从过去的那种一次性的进程的做法中迁移到应用程序的长时间运行的进程。

这些特点很好地引导着它们自己去快速的部署应用程序,因为人们可以不再去假设他们要部署环境是什么样子。这样就允许底层的云平台可以使用一种简单并且一致的机制,自动化变得简单了,可以很快的构建一个新的环境并把这些app部署到这些环境上去。通过这种方式,twelve-factor 模式可以让我们的速度得到很大的提升。

这些特点也同时让我们的idea比较短命,或者说我们扔掉一个应用程序仅仅需要很少的成本。应用程序环境本身是百分之百通用的,任何应用程序状态,要么在内存中要么被持久化,都被抽象出来到baking service那里去获取。比如分布式缓存系统,比如各种数据库。这就使得应用程序可以通过一种简单而弹性的扩容和缩容,从而轻松地实现自动化!在大多数情况下,底层的平台只需要简单的复制已有的环境,再加上所需的数量,然后启动这些进程。需要缩容的时候直接关闭一些运行的进程然后删除掉这些环境就可以了,不用额外的像过去一样去做备份或者要去做一些保存这些环境状态的工作。这样的话,十二因素模式使得我们的扩展性得到优化。


总之,应用程序的一致性使得底层平台可以自动的从错误的的事件中恢复过来。

更重要的是,把日志作为事件流这种做法极大地增强了透明性,让我们可以窥探到应用程序运行时的一些内部及底层行为。环境们的公平性,配置机制以及backing service管理的一致性使得云平台可以提供良好的透明度,让我们可以深入到应用程序运行时的各个方面。这样的话,十二因素模式也使得我们的安全性得到保证。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2016-12-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏take time, save time

python 爬虫 入门 commit by commit -- commit8

代码你可以在https://github.com/rogerzhu/relwarcDJ 上得到,并且带有我完整的commit记录。

690
来自专栏恰同学骚年

《大型网站技术架构》读书笔记四:瞬时响应之网站的高性能架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

1002
来自专栏ImportSource

微服务下持久化观念转变

过去当我们开发一个企业应用的时候,我们经常首先会考虑的是“我们怎么和数据库交互”?最近的一两年来,人们慢慢的开始转变了,可能要问“我应该用哪种类型的数据库?是用...

29310
来自专栏服务端技术杂谈

动手撸一个规则引擎

最开始听说过规则引擎可能是一个类似于OA的系统中,通过规则配置,让一个审批流程得到配置化和规则化。

1734
来自专栏腾讯云数据库(TencentDB)

如何设计和实现高可用的MySQL

王甲坤,腾讯高级工程师、腾讯云关系型数据库MySQL负责人,拥有多年客户端、数据库研发经验。在IOS客户端、MySQL、PostgreSQL、SQL Serve...

10.5K4
来自专栏张善友的专栏

从APM角度上看:NoSQL和关系数据库并无不同

Michael Kopp拥有十年以上C++、Java/JEE的架构及开发经验,现Compuware技术策略师,专攻大规模产品部署的架构和性能。 以下为译文: 传...

2378
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

1491
来自专栏叁金大数据

存储是怎样炼成的?

什么FAT,NTFS,NFS,DAS,SAN,NAS,OSD这些名词我一个都不认识。

1633
来自专栏Java架构师学习

分布式锁的技术选型及思考锁和分布式锁总结参考

本文来自作者 一行 在 GitChat 分享的{分布式锁的技术选型及思考} 锁和分布式锁 在计算机中,锁的作用是解决在并发状态下的共享资源互斥问题,保证在...

3148
来自专栏Android群英传

Android工程模块化平台的设计

704

扫码关注云+社区

领取腾讯云代金券