前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >微服务应具备的12个属性

微服务应具备的12个属性

作者头像
ImportSource
发布2018-04-03 15:29:32
1K0
发布2018-04-03 15:29:32
举报
文章被收录于专栏:ImportSourceImportSource

该文翻译自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管理的一致性使得云平台可以提供良好的透明度,让我们可以深入到应用程序运行时的各个方面。这样的话,十二因素模式也使得我们的安全性得到保证。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 ImportSource 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档