所属分类: 云计算&大数据 整理: FengNet.Com 更新日期:2017/2/13 17:26:00 阅读次数:1219

迁移到原生云应用架构




马特.斯泰恩 著

KVM云技术社区/翻译组出品

译者序
现在是云计算时代,云计算不仅是一种IT资源的使用方式,并且已经演变成一种生态,它给软件架构设计也带来深刻影响,微服务的设计就是为了服务云时代。如何基于云做软件架构设计,或者如何让自己原来的软件架构能迁移到云上,本书给出了原理和初步的方法,相信能给读者带来一些启示。
本书是KVM云技术社区翻译小组两个多月的结晶,特别感谢以下几位KVM云技术社区金牌翻译者:
雷通QQ:824517369,完成了第一章部分内容的翻译
武楠 华讯网络顾问工程师 QQ:963209770,完成了第一章的翻译
何涛涛 平安科技开发工程师 QQ:1849649074,完成了第二章的翻译
贾文杰 甲骨文中国 QQ:1141913371,完成了第三章前半部分的翻译
韩卫 海康威视虚拟化工程师 QQ:499349274,完成了第三章后半部分的翻译
另外,肖力完成了本书的校对和排版工作。
欢迎大家关注KVM云计算社区订阅号“KVM虚拟化实践”,分享在云计算/虚拟化项目实施中的资讯、经验、技术,坚持干货、原创,请大家扫描二维码关注:

翻译的过程是译者和作者思想沟通的过程,也是一个学习的过程,中间充满艰辛,也充满快乐,欢迎大家加入KVM云技术社区翻译小组,一起交流、学习、提高,加入请联系群主(群主微信:xiaoli173702,群穿越使者北极熊微信:hadxiaer)。
关于本书错误和相关讨论,也请联系群主或者北极熊,加相关的微信群一起讨论。
KVM云技术社区翻译小组
2016年5月23日



目录
译者序
第一章原生云的崛起
为什么是原生态云应用架构?
定义原生云架构
总结
第二章变革是当务之急
文化变革
从信息孤岛(Silos)到DevOps
从间断平衡到持续交付
从集中管理到分散自治
结构变革
业务能力团队
平台运维团队
技术转变
分解巨石
分解数据
容器化
从管弦乐编曲到舞蹈编排
总结
第三章迁移手册
分解方法
新功能即微服务
隔离层
扼杀巨石(整体架构)
潜在的结束状态
分布式系统方法
版本和分布式配置
服务注册/发现
路由与负载均衡
容错
API网关/边缘服务
总结


第一章原生云的崛起

软件正在吞噬这个世界
—马克.安德森(Mark Andreessen)
近年来,一直被拥有根深蒂固的传统思想的大佬们统治的企业正在被快速打乱,他们正在被以软件为核心的企业所破坏。例如Square, Uber, Netflix, Airbnb,和Tesla等公司,这些公司持续快速增长,拥有非公开市场估值,令业内历来领头的企业刮目相看。那么,这些富于创新精神的公司有什么共同点呢?
超快创新速度
持续可用的服务
弹性web
以移动为中心的用户体验
迁移到云是软件的自然演化,原生态云应用架构是这些公司获得他们这种破坏性特征的核心。云,我们指的是能以按需、自助的方式弹性提供和释放计算、网络和存储资源的任何计算环境。这个定义包括公有云基础设施(例如AmazonWeb Services, Google Cloud, 或者Microsoft Azure)和私有云基础设施(例如VMwarevSphere 或者OpenStack)。本章节我们将会解释原生云应用架构如何能够具有创新特性。然后我们会验证原生云应用架构的一些主要特性。

为什么是原生态云应用架构?
首先我们要研究转向云原生应用架构背后的共同动机。
速度
众所周知,市场经济,速度制胜。能够快速创新,实验,并交付基于软件的解决方案的企业对于那些遵循传统交付模式的企业是极具竞争力的。
在传统企业中,提供新应用环境和部署新版本的软件所花费的时间通常以天、周、或月计。这种缺乏速度的方法,严重限制了任何一个发行版本所能承担的风险,因为产生和修补错误的成本也在同一时间段内衡量。
互联网公司经常被提及他们每天数百次部署的实践。为什么频繁部署很重要?如果你能从错误中几乎立即恢复,你就可以承担更多的风险。如果你可以承担更多的风险,你就可以尝试大量试验——其结果可能会变成你的下一个竞争优势。
基于云的基础服务设施的弹性和自服务的天性很自然的给予它自己这种工作方式。通过调用云服务API来提供一个新的应用环境要比通过基于表单的手动过程快很多。通过另一个API部署代码到那个新环境可以大大加快速度。给持续集成/建立服务器环境添加自服务和钩子(函数)可以增加更快地速度。最终我们可以从精益大师MaryPoppendick的问题和答案来感受一下这种速度:“你的团队要花费多久时间,只用一行命令行就可以部署一个变化”,“几分钟或者几秒”。想象一下,如果可以拥有如此快的速度,你的团队你的业务可以做哪些事情?
安全
极其快是不够的。如果你上车把油门踩到底,最终你会发生代价高昂的(或是致命的)交通事故。运输方式如航空和特快子弹头列车建造时兼顾速度和安全性。原生云应用架构平衡快速变动的需求和稳定性、可用性和耐久性的需求。这是可能达成而且有必要实现的。
正如我们已经提到,原生云应用架构使我们能够迅速地从错误中恢复。我们谈论的不是错误预防,这是企业里诸多花费高昂的时间所做的程序工程关注的重点。前期的庞大的设计,详尽的文档,架构审查工具,和漫长的回归测试周期都浮在我们苦苦寻找的速度的表面。当然,所有这些做法都是出于好意。不幸的是,他们没有一个能提供一致可衡量的对于大量缺陷的有效改善。
那么我们怎样做才能更快更安全呢?
可视化
我们的架构必须提供当错误发生时能看到它的工具。我们需要能够度量一切的能力,建立一个“什么是正常的”的配置文件,检测偏差(包括绝对值和变化率),并确定这些偏差的组成部分。功能丰富的指标,监测,报警和数据可视化框架以及工具是在所有的云原生应用架构的核心。
隔离故障
为了限制与故障相关的风险,我们需要限制可能会受到故障影响的组件或功能的范围。如果每次亚马逊的推荐引擎挂掉后就没有人能从Amazon.com上买东西,那将是个灾难。整体应用架构往往具有这种类型的故障模式。原生云应用架构通常采用微服务(“Microservices”)。通过微服务组合系统,我们可以把任意一个微服务的错误单单限定在该微服务上,但前提是加上容错。
容错
把一个系统分解成可独立部署的组件是不够的;还要防止其中一个组件的错误通过其可能存在的多个传递依赖关系造成级联故障。MikeNygard 在他的《ReleaseIt! - Pragmatic Programmers》一书中描述了一些容错模型,最受欢迎的是断路器。软件断路器的工作原理非常类似于电子断路器:通过断开它保护的组件与故障系统的其余部分之间的回路来防止级联故障。它还可以提供一个优雅的回退行为,比如回路断开的时候一组默认的产品推荐。我们将在“容错Fault-Tolerance”一节(第36页)详细讨论该模型。
自动恢复
利用可视化,错误隔离,容错,我们具有所需的工具来识别错误,从错误中恢复,并在参与识别和恢复的过程中给我们的客户提供一个合理水平的服务。某些错误容易识别:每次发生他们都呈现相同的容易探测的模式。以服务健康检查为例,通常有一个二进制应答:健康或不健康,启动或未启动。大多时候我们每次遇到这样的错误会采取同样的行动。在失败的健康检查的情况下,我们通常会简单地重新启动或重新部署有问题的服务。原生云应用架构在这些情况下不需要等着手动干预。相反,他们使用自动检测和恢复。换句话说,他们让电脑带上寻呼机,而不是人。
弹性扩展
随着需求增长,我们必须弹性扩展来满足需求。过去,通过垂直地扩大规模能力来处理更多的需求:我们买更强的服务器。我们最终实现了目标,但是这个过程很慢并且代价很大。这会导致只根据峰值使用量预测来规划能力值。我们经常会问“这个服务需要的最大计算能力是多少”。然后,购买足够量的硬件来满足这个数量级。很多时候我们知道这是错误的,然而我们不得不扩大我们的计算能力一应对极端情况,例如在黑色星期五。我们负担着成百上千台轻负载CPU的服务器,使用率很低,这令我们经常感到悲哀。
创新型的公司通过两个开创性的举动来解决这个问题:
代替继续购买更大型的服务器,他们使用大量的更便宜机器来水平扩展应用实例。这些机器更容易获得,并且能够快速部署。
已有大型服务器的低使用率可以通过虚拟化成几个小型服务器,并部署多个逻辑隔离的工作来提升负载。
由于像AWS那种的公有云基础设施变得随时可用,这两个举动也可以融合在一起。虚拟化的工作由云服务提供商来承担,客户关注其应用水平扩展部署在很多云服务器实例上。最近,另一个转变也正在兴起,也就是将虚拟化服务器迁移到容器中,作为应用部署的一个单元。我们将在26页(原书26页)讨论容器。
这种向云端的转变为更多的创新敞开了大门,随着很多公司不再需要花费大量启动资金来部署他们的应用。后续的维护也需要更低的成本投资,通过API实现服务供给不仅提高了初始部署速度,我们还可以对随时变化的需求最大程度地优化服务,提高更快的变更速度。
不幸的是,所有这些好处都是有代价的。应用架构设计必须是水平化的而不是垂直化。云弹性需求变化无穷。我们不仅必须能够快速创建新应用实例,而且还必须能够快速安全地应对。这种需求也带来了管理的问题:如何应对服务的持久性?传统方法例如集群会话和共享文件系统在大多是垂直架构中应用的不是很好。
另外一个原生云应用架构特征是将内存中数据网络,缓存和持久的对象存储等状态形象化,使得应用实例本质上无状态。无状态的应用可以快速创建或者销毁,也可以快速和从外部状态管理器连接或者分离,以增强我们对需求变化的应变能力。大多数云基础设施提供者已经认识到这种特征的必要性,并且提供了这种服务的健康状态菜单。
移动应用和客户端的多样化
在2014年1月,在美国,移动设备在互联网使用设备上占比55%。那些将应用绑在桌面电脑终端,让用户使用的时光已经过去。相反我们必须假设我们的用户将多核心的超级电脑装在口袋里并四处奔波。这点对我们的应用架构做出了很大的暗示,也就是说更多地用户可以随时随地地使用我们的系统。
以查看活期存款余额为例。这个任务过去是通过给银行客户中心打电话,或者去ATM取款地点,或者去询问银行分行的某个出纳员来完成的。这些客户交互模式对任何时间段内的银行底层软件系统的部署要求产生很大限制。
迁移到在线银行系统的服务带动了访问量需求增长,但仍旧不能从根本上改变这种交互模式。依旧需要到电脑终端与系统进行交互,这就限制了访问需求。只有当我们都开始,就像我的同事AndrewClay Shafer经常说的“口袋里装着超级电脑四处奔波”,我们才对这些系统试压。现在成千上万的客户可以和银行系统随时随地地交互。一个银行高管说过在发薪水那天,客户会每隔几分钟查看他们的余额多次。原遗留的银行业务系统架构不能满足这种需求,然而原生态云应用架构是可以的。
移动平台的多样性也对应用架构提出了需求。在任何时刻,客户们都可能想要从不同厂商生产的设备上与我们的系统做交互,这些设备上运行着各种各样的操作系统,同一操作平台的多个版本,甚至不同设备类型(例如手机和平板)。这不仅对移动应用的开发者们提出很大挑战,并且也对终端服务的开发者们同样提出了各种限制。
移动应用经常要和多种旧系统以及多种原生云应用架构的微服务进行交互。这些服务不可能设计成可以支撑客户使用的各种不同移动平台的特殊需求。这些不同的服务集成在一起会对移动终端产生很大的负担,而这些负担会增加使用的延迟以及网络负载,导致反应时间变慢,电池耗电量高,最终导致客户删掉你的应用。原生云应用架构利用API网关这种设计模式也可以支持移动领先概念,这可以将服务聚合带来的负担转化给服务器端。我们将在第47页(原书)API网关/边缘服务章节讨论API网络模式。
定义原生云架构
现在我们将探索原生云应用架构的几个主要特征。基于上面的原因,我们也会对这些特征加以诠释。
原生云应用的十二个因素
云原生应用架构被总结为十二因素应用模式,这个模式最早是由一名Heroku的工程师开发出来的。它描述了一个应用的原型,很好地诠释了使用原生云应用架构的原因。通过强化详细配置,无状态/零共享水平扩展的过程,以及整体松耦合架构的部署环境,来关注模式的速度,安全以及扩展。像CloudFoundry,Heroku,Amazon ElasticBeanstalk这样的云应用平台都使用十二因素应用。
基于十二因素的上下文关联,应用就变成了一个单一部署单元。多个联合部署的单元就是一个应用。这样的话,我们会把多个联合部署的单元当成一个分布式系统。
具有十二个因素应用的具体描述如下:
代码库
每一个部署的应用都在版本控制代码库中被追踪。在多个部署环境中,会有多种部署实例。
相关性
通过合适的工具(例如Maven,Bundler, NPM),应用可以很清晰地对部署环境公开和隔绝依赖性,而不是模糊地对部署环境产生依赖性。
配置
配置,或者其他可能在部署环境(例如研发,展示,生产)之间区别的任何代码,可以通过操作系统级的环境变量来注入。
后端服务
后端服务,例如数据库或者消息代理,作为附加资源,同等地在各种环境中被消耗。
建立,发布,运行
建立部署应用,应用与配置结合,结合后一个或几个程序开始运行,这几个阶段是严格分开的。
过程
应用以一个或多个无状态不共享的程序(e.g.,master/ workers)运行。任何必要状态都被边缘化到后端服务(缓存,对象存储等)。
端口绑定
每个应用的功能都很齐全,通过端口绑定对外提供所有服务(包括HTTP)。
并发性
并发性即通常可以依靠水平扩展应用程序来实现(虽然程序也可以通过内部多线程的方式多路径管理工作。)
可任意处置性
那些快速启动和缓和关闭的程序可以将系统健壮性达到最大化。这些特性允许系统快速弹性扩展,改变部署以及故障恢复等。
Dev/prod 一致性
保持研发,展示,生产环境尽可能的相似,这样可以提供应用的持续交付和部署服务。
日志
除了管理日志文件,还可以将日志当作事件流。通过集中服务,在执行环境来收集,聚合,索引和分析这些事件。
管理程序
行政类或管理类任务,例如数据库迁移,在与应用长期运行的程序相同环境中,作为一次性程序运行。
当没有对即将部署的环境给予适当的考虑时,这些特征可以使它们很好的快速部署应用。这种对环境缺少假设的情况,需要底层云平台采用一种简单且一致的机制,自动化地快速提供一个新环境将这些应用部署在上面。因此,带有十二个因素应用模式可以最大程度提高应用部署速度。
这些特征也可以使它们适用于生命周期短的事务,或者那些我们以最少成本淘汰的应用。应用环境本身就是100%可处理的,因为任何一个应用状态,在内存中或者持久性存储中,都可以被提取到某个后端服务。这样我们可以很容易地自动化弹性扩展或者缩减应用。大多数情况下,底层平台可随意多次简单地复制已有的环境并启动程序。缩减是通过终止运行程序,并删除环境来实现的,当然你可以选择不花费精力去做备份或者保留这些环境的状态。这样,带有十二个因素的应用模式将扩展性实现最大化。
最后,应用的可处置性使得底层平台自动且快速地从故障中恢复。而且,将日志作事件流可以大大增加底层应用运行行为的可见性,这种环境之间的同等性和配置机制的一致性以及后端服务管理机制,可以使云平台对应用运行结构的各个方面进行全方面可见性监控服务。这样带有十二个因素的应用模式,将安全性实现最大化。
微服务
微服务代表了将单个业务系统分解成独立可部署的一种的服务,这种服务只专注做一件事情并且做好。而这件事情通常可以是业务能力,或者提供业务价值的最小单元服务。
微服务架构从以下几个方面实现速度、安全和弹性扩展。
我们可以将业务域按功能界限分为独立的可部署的能力环境,也可以分解为与之相关的可变周期。只要这些变化被限制在一个单一的有限制的环境下,这项服务就可以继续完成它已有约定的任务合约,这些变化可以修改,并与其他剩余的业务任务合作部署。结果就是实现更加频繁更加快速地部署。
软件开发可以通过扩展开发组织自身实现加速。增加开发人员会导致过度的沟通和协调,难以实现软件开发加速。FredBrooks多年前教过我们,把更多人添加到一个延期的软件项目中只会让这个项目更加延期。然而除了将所有的开发者塞进一个沙盘中,我们可以通过设定环境界限创建更多的沙盘来建立一个平行的工作流。
如果我们减少对业务域以及已有代码认知的工作负载,省略掉建立小团队关系的复杂,那么新添加到沙盘工作中的开发者的工作效率和产能就会提升。
采用新技术可以加速。大型整体应用架构通常与长期技术栈合约息息相关。这些合约不仅仅与之相关那么简单。在大型架构中,技术选型带来的问题会付出昂贵的代价,因为这些问题污染整个企业架构。如果我们在单一个体范围内采用新技术,就可以将隔离风险并将它最小化,同样我们可以将运行故障时间隔离,且最小化。
微服务能提供独立有效的服务规模化扩展。大型整体架构可以规模化扩展,但是需要将所有元素都进行规模化扩张,而不是简单地只针对重负载元素。微服务规模化扩展,只跟与之相关的负载需求有关。
自服务敏捷基础架构
开发原生态云应用架构的团队,只对他们自己部署和运行的操作负责。成功的原生云应用的选择者拥有一支自服务平台的全责团队。
就像我们创建业务能力团队为每一个界限环境建立微服务,我们可以创建一支能力团队负责提供平台,在平台上部署运行这些微服务。(见第22页“平台运行团队”)
这些平台的好处在于可以为他们的客户提供基本的抽象层。利用IAAS资源,我们通过API创建虚拟服务器实例,网络以及存储,然后部署各种配置管理和自动化工具,最终将应用和支持服务运行起来。现如今平台逐渐兴起,这会让我们从应用和后端服务角度来思考问题。
应用代码仅仅只是以预先建立人工产品,或者GIT远程源代码形式的“推进”的产物(也许这些人工产品是作为持续交付流水线生产的),然后平台建立应用人工产品,创建应用环境,部署应用,运行必要的程序。团队没有必要思考他们的代码在哪运行或者如何运行,因为平台可以透明地处理好这些问题。
支持后端服务的模式是一样的。需要数据库吗?消息队列或者邮箱服务器?我们可以简单地询问平台来提供满足你的需求。目前平台支持一系列的SQL/NoSQL数据存储,消息队列,搜索引擎,缓存和其他重要的后端服务。通过必要认证,将服务实例自动注入到你的应用环境中供其消耗,它们就可以与你的应用绑定在一起。很多凌乱的易出错的自动操作就被消除了。
这些平台也可以提供一系列额外运行能力:
自动按需扩展的应用实例
应用健康管理
通过应用实例实现访问的动态路由和负载均衡
日志和度量的聚合
这些工具的结合确保能力团队能够以敏捷原则,开发和运行服务。

基于API的协作
唯一原生态云应用架构之间的服务互动模式就是通过发行的各种版本的API。这些API都是典型地带有JSON序列化的HTTP REST形式,但也可以使用其他协议和序列化格式。
假设开发团队在不破坏任何已有API协议的前提下,他们能够按需随时部署新功能,并且不用和其他团队同步。当与业务服务交互时,基本的自服务基础设施平台交互模型也是一个API。那些相同的请求被提交给一个API,就能实现自动处理这些请求,而不是提交给供给,规模扩展和维护应用的基础设施。
遵循协议可以通过客户驱动协议在服务到服务交互的两端进行验证。服务消费者不允许获得相关性私有实现细节或者直接访问相关数据存储。事实上,只有一个服务曾经允许获得直接访问任何数据存储的权利。这种强迫解耦合方式直接支持原生云速度的目标。
抗脆弱性
抗脆弱性的概念是从NassimTaleb 的Antifragile书中引入的。如果脆弱性是系统的一个特征,那么这个系统会变得越来越弱,或者遇到压力就会出现故障,那么这个特性的反面是什么呢?很多人会给出健壮性或者弹性这样的答案,也就是当遇到压力时,系统不会出现故障或者变脆弱。然而,Taleb谈到脆弱性的反面是抗脆弱性,或者一个系统遇到压力时会变更强。什么样的系统能够到达那种程度呢?想一想人类的免疫系统,哪个功能遇到病原体会变得更强,而当隔离病原体后变弱呢?我们能不能建立一个那样的架构?
原生态云架构的选择者设法创建这样的一个架构。NetflixSimian Army project就是一个例子,通过著名的“ChaosMonkey”子模块,将随机故障插入到生产元素中,实现识别和删除架构中脆弱性。明确地找出应用架构中的脆弱性,插入故障因素,强迫修正,最终这个架构会自然地趋于实现更高级别的安全性。
总结
在本章中,我们从通过软件为业务提供的能力的角度,验证了迁移到原生云应用架构的共同动机。
速度
具有比我们竞争对手更快地创新,实验,交付价值的能力
安全
在维持稳定性,可用性和持久性的同时,快速移动的能力。
规模扩展
根据需求的改变,弹性地应对能力。
移动性
我们的客户可以无缝地从任何时间和地点,在任何设备上,都能与我们进行交互的能力
我们也验证了原生态云应用架构的独有的特征,以及它们可以帮助我们提供这些能力的方式。
带有十二个因素的应用
一系列模式可以将应用的速度,安全和规模化扩展实现最优化设计
微服务
这种架构模式可以帮助我们将部署单元和业务能力联合起来,允许每一个能力都能独立自主地移动,并且更快更安全。
自服务敏捷基础设施
云平台可以使开发团队以应用和服务抽象层的形式操作,提供基础设施层的速度,安全和规模化扩展
基于API的协作
这种架构模式是将服务对服务的交互作为自动可验证的合约模式,通过这种简化集成模式使服务的速度和安全成为可能。
抗脆弱性
当我们对系统的速度和规模施压,系统会提升反应能力,增强安全性
在下一章,我们将验证一些大多数企业为了采用原生态云应用架构而需要改变的事情。


第二章变革是当务之急
所有我们需要做的是盯着这样一个时间线,从收到客户的订单开始直到我们赚到现金。并且,我们要通过去除没有价值的东西,来缩短时间线。
——丰田公司 大野耐一(Taichi Ohno)

Taichi Ohno是公认的精益生产(LeanManufacturing)之父。尽管精益生产的实践没有被完美地应用到软件开发领域,它的原理却通常被应用到。对传统IT企业组织采用原生云(cloud-native)应用架构需要做出的必要改变,以及拥抱变化当中的文化转变和组织变革,都具有很好的指导作用。
文化变革
IT企业采用原生云应用架构需要大量且必要的转变,而不仅仅是技术上的转变。其中包括文化变革、结构变革,这些以消除产生冗余的组织、流程和活动为中心的变革。在这一节,我们将要探索必要的文化变革。
从信息孤岛(Silos)到DevOps
传统IT企业通常会将组织会分成以下几个孤岛(Silos):
软件开发
质量保证
数据库管理
系统管理
IT运维
发布管理
项目管理
这些岗位被创建来让那些有专长的人来指导那些专业的方向。并且这些岗位通常有不同的管理层级、工具集、沟通习惯、词汇表、激励机制。在如何完成IT企业的目标这个问题上,这些不同会激励出的不同榜样。
一个经常被列举的例子是开发和运维在是否改变架构这个观点上存在矛盾。开发的任务通常被认为是通过开发新的特性来增加组织的附加值。这些特性,很自然地给IT生态带来了改变。所以开发者的任务被描述为“带来改变”,能够激励他们的是带来了多少改变。
相反,IT运维的任务可以被描述为“组织改变”。为什么呢?IT运维通常被赋予维护不同层面IT系统的可用性、容错性、性能和持久性。所以他们的目标是维持关键表现指标(KPIs),例如:平均宕机时间(MTBF)和平均恢复时间(MTTR)。其中一个给这些指标带来风险的因素就是对系统添加新的特性。因此,相比找到方法来安全地引入开发想要的改变到IT系统,IT运维下意识的反应往往是过程很痛苦,这样就减慢了变更的速度。
这些不同的范例很显然地带来很多多余的次优的协作。协作、沟通和简单工作接手,在最好的情况下变得乏味而痛苦,乃至是绝对混乱的(甚至是危险)。IT企业试图通过创建诸如投票系统和委员会议的繁重流程来“修复”这种情形。从而使IT企业的价值流在无价值冗余的重压下,开始下降。
这样的环境完全与原生云的追求速度的观点相反。对创建一个安全的环境的渴望,通常激励了专门的岗位和流程的产生。然而,他们仅会带来很少的额外安全,甚至在某些情况下,让情况变得更加糟糕。
从核心来说,DevOps代表着拆卸不同的分工,建立共享的工具集、词汇表和交流结构。从而服务于有共同目标的文化。这个目标是快速安全地传递价值。激励机制被创建来加强和奖励引导组织到目标所在的方向上的行为。官僚和流程被信任和问责制所取代。
在这个新的世界,开发和运维向相同的直接领导报告,通过合作来发现不仅持续创造价值,而且达到期望的可用性、容灾性、高性能、持久性的实践。今天这些上下文敏感的实践,越来越多地采用原生云应用程序架构来提供技术支持,从而完成组织的新的共同的目标。
从间断平衡到持续交付
企业经常采取敏捷流程,如Scrum,但仅仅是开发团队的局部优化。
作为一个产业,我们相当成功地完成了从单枪匹马的开发团队到敏捷开发的团队的转变。我们可以全面启动项目,编写用户需求,实施敏捷开发的所有日常事务,如迭代规划会议,每日站立会议,回顾总结和向客户展示演示。我们当中喜欢冒险的,甚至敢于在工程实践中冒险,例如:结对编程和由测试驱动的开发。持续集成,这曾是一个相当激进的概念,现在已经成为一个标准的企业软件词库的一部分。事实上,我一直是已经建立了高度优化的“演示故事”周期的几个企业软件团队的成员,每个开发迭代的结果是在向客户演示期间被热情地接受。
但是当这些团队被问到那个可怕的问题:
我们什么时候可以在生产环境中看到这些特性?
这个问题我们很难回答,因为这要我们必须考虑超过我们能控制的不可抗力:
我们需要多长时间才能通过独立的质量保证流程?
我们什么时候才能赶上产品发布的火车?
我们能够让运维及时地部署好生产环境吗?
因此,我们意识到我们被嵌入到DaveWest所说的waterscrumfall。我们的团队正转变成拥抱敏捷原则,但是我们的组织结构没有。因此,并不是每次迭代都会带来生产部署(这是工作软件价值的这个敏捷宣言的最初的意图),而是代码实际上是成批的参与更传统下游的发布周期。
这种操作风格会带来直接的后果。我们继续以“间断平衡”(punctuatedequilibrium)的风格交付,而不是每次迭代都能把价值带给用户,把有效的反馈带给开发者,间断平衡交付丧失了敏捷交付的两个关键优势:
用户或许在数周内都看不到软件有哪些新的特性。他们认为这种新的敏捷运营就是“换汤不换药”,并没有给开发团队更多的信赖。因为没有看到一个可靠的交付节奏,他们恢复到以前的实践来发布尽可能多的需求。为什么?原因在于他们没有信心软件会很快交付,所以想让它在交付时包含更多的价值。
开发团队会在数周的时间内没有获得真实的反馈。虽然演示很好,但是有经验的开发者都知道在真实用户参与到软件开发的过程当中来才会获得最好的反馈。这种反馈会提供很好的错误纠正,让开发者去做正确的事情。当推迟反馈后,很可能错误的设计越来越多,带来花费高昂的返工。
获取原生云应用架构的优势要求我们做一个可持续交付的转换。我们拥抱端到端原则的价值,而不是被waterscrumfall组织驱动的间断平衡。一个对于展望这种生活方式的有用的模型是“概念到现金”的观点,这个观点被Mary和Tom在他们的书《Implementing LeanSoftware Development》中提出来。这个方法考虑将一个商业的想法从概念转化为利润点所必须的动作,构造一个使人和流程朝向目标取得最大的成就的价值流。
我们在技术上支持这个工程实践持续交付的工作方式,这样,每次迭代(事实上,每一段代码都是有用的)被证明是可自动化部署的。我们通过构建部署管道,让每次测试都实现自动化,从避免生产部署测试失败。剩下的唯一决策是一个商业决策:现在部署新的可用的特性有很好的商业价值吗?我们确定他们的功能和我们承诺的一样,但是我们要把他们提供给我们的客户吗?因为部署管道是完全自动化的,所以必须由商业决策来按下这个按钮。
从集中管理到分散自治
这个waterscrumfall文化的一部分值得特别的关注,正如我所见,它成为采用原生云应用架构的关键点。
企业通常在应用程序体系结构和数据管理中,采用集中式控制结构,委员会负责维护指导方针和标准,并且批准个人设计和更改。集中式控制旨在帮助解决几个问题:
避免大范围技术栈的不一致,减少组织的总体维护压力。
避免大范围的技术架构选型的不一致性,形成整个组织应用程序开发的共同观点。
像法规遵从这样的跨领域的关注点会对整个组织做同等处理。
数据的归属会由对所有的组织关注点有广泛认识的人决定。
这些结构的创建,是期待他们能够将带来高质量,低成本,或两者兼而有之。然而,这些结构很少带来所期望的质量改进或节省成本,甚至阻碍原生云应用程序架构所寻求的交付速度。正如整体应用架构会带来限制技术创新速度的瓶颈,整体管理结构同样会这样。架构委员会通常周期性组建,从而长长的工作等待队列往往接踵而至。即使是很小的数据模型变化,在这些变化只需要在数分钟或数小时内实现,也必须准备好被架构委员会许可,这会在越来越长的待做事物栈中荒废了。
采用原生云应用架构通常伴随着分权管理。建立原生云应用的团队(见第21页“业务能力团队”)具有交付所需的各方面能力。他们拥有和管理数据、技术栈、应用架构、独立部件的设计以及封装API提供给公司其他人使用。如果需要做一个决策,会由团队自主决策。
独立团队的分权和自治被最小的、轻量级的结构所平衡,结构被强加在使用独立开发和部署服务之间的集成模式上(例如:他们更喜欢HTTP、REST、JSON、APIs,而不是不同风格的RPC)。这些结构通常出现在底层问题的解决方案,例如:容错性。团队被激励自己想办法解决问题,然后自发组织其他团队建立通用模式和框架。当一个对于整个公司来说不错的解决方案出现了,解决方案的拥有权通常被转移到一个云框架或者工具团队,这个团队可能会也可能不会被嵌入到平台运营团队(见第21页“平台运维团队”)。同样,这个云架构或者工具团队经常是对架构的共识做出改革的开拓者。
结构变革
在本章中,我们将研究在采用原生云应用体系架构时,组织在如何构建团队。这种重组背后的理论是一个著名的观察,被称为康威定律(Conway’s Law)。我们的解决方案是在每一个长期的产品周期中,创建一个结合不同学科员工的团队,而不是把属于一个单独学科的员工隔离出来,比如测试。
业务能力团队
对于任何设计系统的组织,其设计出的产品是组织交流结构的副本。
——梅尔文康威(Melvyn Conway)

我们已经在第16页的“从silos到DevOps”中讨论了组织IT组织架构设计成孤岛(silos)的实践。很自然地,创建这些孤岛之后,我们也把个人放进这些孤岛的联盟。但是在我们需要生产一个新的软件的时候会发生什么呢?
一种很常见的做法是委托给一个项目团队。这个团队被分配一个项目经理,项目经理与各种孤岛合作,来获得每种专业的“资源”,为这个项目配备人员。我们从康威定律中学到的一部分是,正如上面引用的,这些团队将在系统设计中很自然地只做他们所精通的部分。所以,我们最后我们以联合这些孤岛的层级的孤立架构结束。这些层级包括:
数据访问层
服务层
网页MVC层
消息层
等等。
这些层跨越了多个可识别的业务能力,这让涉及独立于其他业务能力的能力很难创新和部署特性。
公司寻求迁移到原生云应用架构,例如:被业务能力划分的微服务,常常需要采用Thoughtworks公司所称的“逆康威回旋余地”。而不是建立一个架构匹配他们的组织结构图,  他们决定他们想要的架构并重组组织架构与那个架构相匹配。如果你这样依据康威定律来做,你所期望的架构最终会出现。
因此,作为到DevOps文化的转变,团队应该按照交叉功能来组织,业务能力团队是在开发产品而不是开发项目。产品付诸长期持续的努力,直到他们不再提供业务价值。(当你的代码不再用于生产环境中,你的使命就完成了!)所有的角色都要开发、测试、交付,并且运维服务,从这才能看出一个团队的业务能力。这些团队通常被组织为“两个披萨团队”,表明如果一个团队不能被两个披萨喂饱的话,这个团队就太大了。
接下来,应该决定创建什么样的团队。如果我们遵循逆康威策略,对于组织来说,我们应该从域模型开始,并寻求确定业务功能,可以封装在有界上下文情况下(我们将在第24页的“分解数据”中讨论)。一旦我们确定这些功能,我们开始创建团队,来管理他们整个有用的生命周期。这样,业务能力团队能够掌握应用从开发到运维的生命周期。
平台运维团队
正如之前在第11页的“自助敏捷基础架构”中描述的,业务能力团队需要依赖于自助的敏捷基础架构。实际上,我们可以认为一种特殊业务能力被定义为“同时具有开发,部署,运维的能力”。而拥有这种能力的就是平台运维团队。
平台运维团队操作自助敏捷基础架构需要用到业务能力团队。这些团队典型地包括传统系统、网络、存储管理员的角色。如果公司以云平台运维为前提,这个团队要拥有管理数据中心的团队,或者和他们密切地合作,也要了解硬件需求,来提供一个基础架构平台。
IT运维通过一系列的投票系统这种传统的方式与客户进行交互。正因为平台运维团队运维了一个自助平台,所以必须采用不同的交互方式。正如平台运维团队和其他人合作基于API接口,平台运维团队为平台提供一个API接口。业务能力团队应该能够采取一个简洁的方式来构建自动发布管道,按需预分配环境和服务,而不是让预分配的应用环境和数据服务请求排队。

技术转变
现在,我们来转向迁移到云的运维开发平台的实现议题。
分解巨石
传统的n层整体的企业应用被部署到云基础架构平台很少能够运维好,原因在于,他们经常在他们的云基础设施不能提供的部署环境上做得不到支持的假设。例如:
使用未挂载的共享文件系统
点对点的应用服务器集群
共享库
配置文件放在常用位置
这些假设大都基于一个事实,整体架构被典型地部署在长寿的基础架构上。不幸的是,他们和弹性短暂的基础架构的思想不兼容。
即使我们不基于这些假设来构建一个整体的架构,我们仍然还有问题:
整体架构把变更周期连在一起,以至于独立的业务需求不能按要求部署,妨碍创新的速度。
嵌入到整体架构的服务不能独立地扩展到其他业务,所以很难高效地加载。
公司新来的开发者必须适应新的团队,经常需要学习新的业务领域,并立即熟悉非常大的代码库。在提供真正的生产力之前,这通常需要增加到3-6个月来适应。
试图增加更多的人力来扩展开发团队,会让组织更加冗余,增加合作和交流成本。
技术栈被引用是一个长期的过程。引进新的技术风险太高,因为它对整个应用会产生不利的影响。
善于观察的读者会发现这个列表与第10页的“微服务”相反。将组织分解为业务能力团队也要求将服务分解为微服务。只有这样,我们才能从我们迁移到云基础架构的动作中获取最大的利益。
分解数据
仅仅分解整体架构成微服务还远远不够。数据模型也必须被分解。如果我们对业务能力团队的期望是自动化的,却必须通过一个单一数据存储来合作,那么整体架构对创新的壁垒仍然矗立在那里。
事实上,产品架构必须从数据开始,这个说法是具有争议性的。这个在域驱动设计(Domain-DrivenDesign)中由EricEvans提出的原理,说道,我们的成功很大程度上被域模型的质量所掌握(并且普遍存在的语言在支撑他)。因为一个与模型要想成功,它必须也是内部一致的——我们不应该在同一个模型中找到前后矛盾的术语或者概念的定义。
创建一个没有矛盾的联合域模型会难以置信地困难,并且花费高昂。Evans将整个域的商业模型内部子集一致称作有界上下文。
当最近遇到一个航空公司客户的时候,我们需要讨论涉及他们业务核心的一些概念。很自然地,“航空预约”的话题被提出来。小组可以数出他们业务内部关于预约的不同逻辑定义,他们几乎不可能复合成为一个。所有定义的细微差别,被小心地烧制成一个单一概念,这会成为组织的一个巨大的瓶颈。
有界上下文允许你在一个组织内部使用单一概念的矛盾性定义,只要他们在文章内部是一致的。
因此,我们开始识别域模型中能保持内部一致性的片段。然后在片段之间划固定的界限,这就是我们的有界上下文。进而,我们能够用这些上下文来匹配业务能力团队,这些团队创建提供这些能力的微服务。
微服务的定义,为你的“12因素应用“应该怎样,提供了一个标题。12因素主要是一个技术规范,然而微服务是一个业务规范。我们定义我们的有界上下文,给他们分配一系列商业功能,委员会功能团队拥有这些商业功能,并且让他们12因素应用。事实是这些应用可以独立部署,这为业务功能团队的运维提供一系列有用的技术工具。
我们将有界上下文和数据库/服务模式结合起来,每个微服务封装、管理、保护自己的域模型,并且持久稳定地存储。在这个数据库/服务模式,只有一个应用服务被允许进入逻辑数据存储,这作为一个模式存在于多租户集群或者一个专用物理数据库当中。任何外部的接入都通过一个定义明确的商业合同,由API执行(通常是REST,但可以是任意一种协议)。
这种分解允许应用程序拥有通晓多种语言的持久性,或者基于数据的形态和读写访问模式来选择不同的数据。然而,数据必须通过事件驱动技术重组,以便询问跨上下文的问题。像命令查询责任隔离(CQRS,command queryresponsibility segregation)和事件发起(eventsouring)这样的技术,在通过上下文相同概念的同步上很有用,但超出了本文的范围。
容器化
容器镜像,例如这些已经通过LXC准备好的,Docker或者Rocket项目,正快速成为原生云应用架构部署的基本单元。这些容器镜像被多种调度解决方案实例化,例如:Kubernetes、Marathon、或者Lattice。公有云提供商Amazon和Google也为容器调度和部署提供了一流的解决方案。容器利用现代Linuxkernel原语,如利用控制组(cgroups)和命名空间来提供相同的资源分配和隔离特性,就类似于虚拟机提供的,但拥有更低的成本和更高的可移植性。应用开发者将会舒服地将应用打包成容器镜像,以此充分发挥现代云基础架构的特性。
从管弦乐编曲到舞蹈编排
不仅仅服务交付、数据模型、管理要去中心化,而且服务集成也是。企业的服务集成传统的是通过企业服务总线(ESB)来完成。企业服务总线成为路由、传输、政策、安全、以及其他决策管理服务间交互的主人。我们称这个为管弦乐编曲,类似于在一个管弦乐队由指挥决定来表演的歌曲。企业服务总线和管弦乐编曲有助于很简单满意的架构图,但是他们的愚蠢是欺骗。通常,隐藏在企业服务总线中的是复杂性的复杂网络。管理这种复杂性变成一份全职工作,而且从事这个工作成为应用开发团队的一个持续的瓶颈。正如我们在联合数据模型中看到的一样,一个像ESB的联合集成解决方案成为一个阻碍速度的巨大的难题。
原生云应用架构,如微服务,趋向于喜欢编排,类似于一个芭蕾舞演员。智慧被放在端点,类似于Unix架构的哑管道和智能滤镜,而不是把智慧放在集成机制中。
当台上的情形与预先的计划不同时,没有在场的指挥来告诉舞者该怎么做。但是,他们会选择适应。同样的,服务通过如客户端负载均衡(第39页的“路由和负载均衡”)和断路器(第42页的“容错”),这样的模式来适应于环境中变化的情形。
尽管架构图倾向看起来像一个复杂的网,他们的复杂度不比传统的SOA大。编排简单地承认和暴露系统必须的复杂性。一旦这个转变支持为了从原生云应用架构中获取速度而要求的自治。团队就能够适应他们不断变化的情形,避免了与其他团队协调带来的很大的开销,也避免了对集中管理的ESB协调变化的开销。
总结
在这一章,我们研究了大多数企业在采用原生云应用架构时所必须要做的一些改变。从人文角度看,主旨就是权利下放和自治。
DevOps
分散技能集到跨职能的团队。
持续交付
分散发布时间表和流程。
自治
分散决策。
我们把这种分散归纳为俩种主要的团队结构:
业务能力团队
跨职能的团队,对设计、流程和发布时间表做决策。
平台运营团队
给跨职能团队提供必要的平台的团队。
并且从技术上,我们也分散控制权:
整体到微服务
对个人业务能力的控制被分布到个人自助服务。
有界上下文
对内部一致的业务域的子集模型的控制被分布到微服务。
容器化
对应用打包的控制被分布到业务职能团队。
编排
对服务集成的控制被分布到服务终端。
所有的这些变化创造了自动化的单元,使我们能够安全地以理想的创新速度前进。
在最后一章中,我们将通过一组操作手册,来深入研究迁移到原生云应用架构的技术细节。

--------------------------------------------------------------------------------

相关文章
传统企业上云的三个正确姿势 2017/1/24 16:16:53
重构并非难在如何做,而是难在何时开始做 2017/1/24 16:13:49
Hadoop、Spark等5种大数据框架对比,你的项目该用哪种? 2017/1/24 16:12:43
大数据等最核心的关键技术:32个算法 2017/1/24 16:11:02
如何在阿里云上构建高可用应用 2017/1/24 16:08:45
接入而非拥有,深入浅出谈云计算经济学的现实价值 2017/1/24 16:08:14
数据中心级交换机选型参考 2015/11/7 10:03:25
如何做好大型数据中心的运维? 2015/9/24 8:53:09
运维的85条军规 2015/9/21 8:54:31
建立变更管理系统 消除数据中心混乱 2015/9/21 8:41:53
iptables官方手册整理 2014/12/18 15:50:54
从CPU和OS到虚拟机和云计算 2014/5/20 9:54:57
当我们谈大数据的时候,谈什么?( 王长胜 ) 2014/4/21 10:39:43
趣谈大数据【华为内部狂转的想象力惊人的好文】 2014/4/21 10:23:16
大数据云安全策略4大窍门 2014/4/18 10:21:16
系分、项管论文写作的一些技巧 2014/2/14 16:46:05
基于IPv6的下一代网络技术的特征分析 2014/2/8 23:22:44
中文Linux Command 2013/5/28 11:25:48
Puppet配置管理工具概念及其工作原理 2012/8/2 10:42:41
构建私有云数据中心的四大关键因素 2012/3/20 16:17:29
配置云计算首先要解决的五个问题 2012/3/19 9:48:16
将物理数据中心向云计算迁移的四大步骤 2012/3/19 9:42:19
虚拟化的两个重要问题:虚拟化备份和灾难恢复与虚拟机蔓延 2011/9/19 16:01:22
如何实现从物理到虚拟基础架构迁移 2011/9/19 15:55:50
如何创建一个用于网络监控的网络性能基线 2011/9/19 15:45:13
数据中心SAN架构设计八大原则 2010/9/29 8:58:29
讲解主流备份软件如何在VMware环境下工作 2010/4/21 16:27:25
安全审计自己动手 2010/4/14 11:12:19
备份与应急恢复系统功能实现 2010/3/31 13:04:58
北京市东城区“十一五”信息化发展规划 2009/11/4 15:22:19
服务器虚拟化后应该注意的八大问题 2009/6/30 19:53:38
如何备份和检修虚拟机 2009/6/30 19:49:45
如何构建和配置虚拟化技术部署项目? 2009/6/30 19:48:27
分析虚拟化部署的评估与规划阶段 2009/6/30 19:47:22
成功迁移VMware Server到ESX3.5的四大步骤 2009/6/23 15:03:51
准备实施虚拟化面临的障碍说明 2009/6/22 13:28:10
分析虚拟化部署的评估与规划阶段 2009/6/22 13:24:48
解析三大容灾技术 2009/6/22 13:22:40
虚拟化环境对存储备份的影响分析 2009/6/22 13:21:44
VTL搭配磁带面临的四大问题 2009/4/24 15:32:45
部署虚拟化的硬件购买策略 2009/4/21 13:11:59
VMware容灾备份功能简介 2009/4/21 13:07:56
在ESX Server环境下的存储管理 2009/4/21 13:06:35
使用快照备份的方法 2009/4/21 13:05:45
如何最大化VMware存储效率? 2009/4/21 13:04:20
在VMware环境里避免存储阵列快照陷阱 2009/4/21 13:03:48
虚拟机备份应该注意的五个问题 2009/3/27 12:23:31
全面出击 让DNS服务器无懈可击 2008/7/31 8:38:03
使用php-syslog-ng远程查看与管理系统日志 2008/5/15 12:58:08
浙江省嘉兴市“十一五”交通信息化规划 2008/2/10 20:59:59
浙江人事、编制2005─2009年信息化建设规划 2008/2/10 20:56:31
浙江省富阳市信息化“十一五”发展规划 2008/2/10 20:51:59
浙江省“金质工程”(一期)建设计划 2008/2/10 20:50:36
宁波市电子政务发展总体规划 2008/2/10 20:48:37
NAC网络准入--整个初始化过程 2008/1/9 9:14:11
NTP网络时钟协议的实现 2007/6/6 15:43:49
Linux 2.6.19.x 内核编译配置选项简介 2007/5/29 7:55:59
Linux 下实现网卡高可用性的几种方法 2007/5/28 17:42:06
Linux软件安装之RPM的安装技巧 2007/5/17 10:49:56
iptables防火墙配置工具ShoreWall的安装和使用实例 2007/3/22 10:32:05
基于FreeBSD5.4全能服务器安装 2007/2/1 17:19:40
常见 iptables 的 firewall 设定配置问题: 2007/1/16 15:07:48
DNS 配置详解 2007/1/16 15:01:02
网络管理实战技术 2006/12/15 10:09:03
网管软件选择的着眼点 2006/12/13 14:09:19
L2与L3 VPN的详细介绍与对比 2006/12/4 16:54:19
新一代网络安全接入技术对比分析 2006/12/4 16:40:41
有关VPN连接的15项故障诊断提示 2006/10/28 9:55:18
网络路由安全攻防对策分析及实践 2006/8/8 18:55:12
信息系统灾难恢复规范 2006/8/4 18:44:19
电子政务特点及其系统安全全攻略 2006/7/29 7:16:55
局域网数据链路层(第二协议层)网络安全 2006/6/13 8:35:01
一些有关网络的故障案例 2006/6/9 20:36:48
入侵检测系统逃避技术和对策的介绍 2006/6/7 9:25:12
网络应用服务安全分析 2006/5/30 7:34:49
构建安全的N层环境 2006/5/25 19:50:04
VSFTPD的高手篇 2006/5/19 16:13:43
CDN的网络架构 2006/5/9 21:06:33
CDN 内容分发网络技术 2006/5/8 15:30:39
网络测试与分析在运营商网络中举足轻重 2006/4/6 19:25:22
适合NGN的VPN承载平台的构建和应用推进 2006/3/28 20:11:18
正确认识宽带路由器的主要参数 2006/3/20 13:10:39
802.1x:老根发新芽 2006/3/8 10:55:52
交换机网络安全策略全方位解析 2006/1/8 16:25:52
Microsoft Security Assessment 术语表 2005/12/14 9:03:06
Configuring Dynamic VLANs 2005/11/24 14:05:15
P2P,改变互联网基础的潜能思想 2005/11/21 9:16:44
强审计:亟待深耕的沃土 2005/11/21 9:05:12
《网络基础学习之十二》交换机的分类 2005/11/11 9:52:55
《网络基础学习之十一》走近交换机 2005/11/11 9:51:45
IPSEC 安全架构、应用及展望 2005/11/5 20:58:28
解析入侵检测系统的性能的辨别方法 2005/9/14 10:51:07
安全防护-入侵检测实战之全面问答(下) 2005/9/14 10:47:29
VPN及其配置示例 2005/9/7 16:06:30
Linux 2.4 Packet Filtering HOWTO 简体中文版 2005/8/19 8:27:48
交换机里的安全因子 2005/8/16 17:32:10
[网工]入侵检测系统FAQ(全) 2005/7/6 21:01:49
IPSec基础-IPSec服务 2005/7/6 21:00:34
交换机(Switch)工作原理 2005/6/22 7:57:16
深度包检测技术工作原理简介 2005/4/26 9:18:02
四项原则保护内部网络 2004/11/16 8:33:38
交换机的种类 2004/11/9 14:19:33
BIOS设置攻略,比较全面! 2004/10/21 8:47:33
网闸40问 2004/7/26 8:43:18
华为的产品分类 2004/6/7 7:57:52
Ghost V8.0 使用详解 2004/3/30 14:52:47
安全事件日志中的事件编号与描述 2004/2/23 15:36:26
Symantec.Ghost.8.0企业版使用全攻略 2003/11/4 8:57:43
【FAQ】RPM软件包使用常见问题 2003/9/17 8:35:09
最佳的75个安全工具 2003/9/5 15:18:38
制作自己的Floppy-Linux Step By Step 2003/8/27 13:12:27
Linux服务器的一些基本应用 2003/8/15 12:11:07
Sino-trade.com集群技术报告 2003/8/12 8:24:37
iptables基础,绝对的基础 2003/7/30 17:17:23
4006交换机(IOS版)简明配置维护手册 2003/7/28 18:02:12
linux应用软件谈之远程桌面控制篇 2003/7/14 8:56:59
关于双连接的负载均衡 2003/7/14 8:49:23
如何规划 Linux 主机 2003/3/24 16:00:23
如何学习 Linux 2003/3/24 15:59:18
什么是 Linux 2003/3/24 15:58:22
Linux服务器的一些基本应用 2003/3/24 10:43:09
深入浅出谈防火墙 2003/3/17 22:45:38
深入浅出谈防火墙 2003/2/21 22:19:40
用iptales实现包过虑型防火墙 2003/1/15 16:55:53
用iptables实现NAT 2003/1/15 16:49:48
Netfilter/Iptables的防火墙功能介绍 1 2003/1/12 16:18:20


感性空间
设计&运维
网络技术
休闲娱乐
NetFilter
linux&Unix
网络安全
程序空间
软件考试
RFC&ISO
规划&规范
虚拟&存储
Apple技巧
云计算&大数据



文章搜索



站内搜索