原文：Microservices à la Service Fabric
作者：Chase Aucoin
翻译：张鑫健；审校：孙薇
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。

Service Fabric框架对微软而言是一大进步。其核心部分是一个分布式系统平台，用于构建可扩展的可靠应用。在便于封装可部署代码的同时，还内置了微服务最佳实践案例。

本文将带您最快地上手使用Service Fabric框架，并保证您会爱不释手。但想要了解Service Fabric框架以及它的重大意义，就有必要了解现代软件发展到今天，在采用Service Fabric框架前，前人们血与泪的历史。

面向对象的黄金时代

在引入面向对象和现代的计算模式之后，计算机界发生了翻天覆地的变化。Visual Basic在1991年面世，真正揭开了现代风格软件开发的序幕，使得开发人员可以专注于商业价值，而不用像之前那样顾虑一大堆硬件特性的问题。之后在这种开发思路下，出现了后来的运行库，比如1995年的Java，2000年的.NET framework和C#。尽管在之后几年中，Java和C#出现了些许变化，但采用的模式和实践方式却没有太大变化。

这些实践、模式以及运行库在进化过程中都有如下共性：内部构架变得原来越抽象，然而使用门槛却越来越低。终端开发者无需操心细枝末节、重复任务和管道问题，从而专注于传达产品的业务价值。

敏捷的诞生

在整个计算机行业的代码编译出现模式和实践范例的同时，我们却忽视了改进提炼围绕着产品开发与SDLC的商业进程。

当时大多数人认为SDLC相关的模式（瀑布、大爆炸/一次性集成、螺旋等）过于死板受限，无法适应开发者新的快速任务执行的能力。开发者在功能构建上的速度已经超过了商业进程的速度，他们将大多时间花在构建需求文档和不注重价值的产品上。

2001年在犹他州Snowbird举行的会议上，有一批先驱者提出了关于SDLC思考方式的指导思想，也就是后人所称的敏捷宣言（Agile Manifesto）。

agileSHERPA提出：

“相比于强调提前规划和需求详尽，本指导思想的重点在于：如何进行持续规划、团队授权、彼此协作、紧急设计、早期测试和经常探究根本，最重要的是能在短期快速迭代中交付软件。”

但在实际应用中，各公司尤其是企业组织最初非常抵触这种思考方式与抽象化商业进程。

而其他人迫切渴望采用这种思想，却完全无法理解。

最终敏捷获得大家的共识。“网络泡沫”崩溃前，各家公司都在追求敏捷，最终演变成了公司之间的军备竞赛。市场上对于敏捷的需求激增，但资源不足使得人们更加关注产品的价值主张和快速迭代。

敏捷性思维的广泛影响一改业内产品产出缓慢（一到两年一个产品）的情况，通过流线化作业，现在可以按季度或者每半年发布一次版本了。实际可用的代码一般会在发布日期前交付使用，但在整个行业内，开发的速度与工程及商业进程的发展仍有断层。

DevOps

尽管在商业与开发进程中出现了前文说的种种进步，但软件的交付流程本质上仍是瀑布式的。一切按部就班，我们仍有季度或月度发布。让事情更为复杂的，则是开发自由与商业敏捷导致面向服务开发所占的比重增加。不同于之前的单一应用部署，现在我们还有很多需求各异的小型应用需要协调。

大部分协调需求都只是因为软件发布不够频繁：只要单体功能已经完成，并且符合质量和业务需求的审验，就应当能够交付使用。

在2008年，工程师、企业领导和运营专家开始推动DevOps，人们渴望一种在整个软件开发周期中工程师和运营者更为协调，同时重视重复工作自动化的环境。

点击这里可以查看视频：DevOps的历史。

风暴来袭

随着公司、工程师和运营者日臻磨合，过去5-10年间有大量代码快速出炉，质量也大幅提高，远胜之前的30年。

现在大部分代码开始老化。八年前我们所使用的编程模式可能也很优秀，但直到两年前商业模式都还不够好。或者开始时想要使用敏捷，却没能坚持最佳实践的开发标准。这方面有很多类似的情况，不过我们的底限是：所有资源无论是现代化的还是较早期的，都要能为企业提供商业价值，需要维护的内容也要满足这个要求。

许多公司开始花费大量精力进行资源协调，努力均匀分切。假设公司有2到5个敏捷开发团队负责一个产品的不同部分，或者干脆就是不同的产品，就会有各种问题：这些项目的着陆点在哪，硬件是哪个队伍的？在最初设计不适用水平扩展或容错性不佳的情况下，如何确保关键程序的高可用性？如果某台机器宕机怎么办？是要继续手头的工作，还是选择损失掉一些信誉，还可能带来负面的口碑？

让服务器不再娇贵，而要成为顶用的老黄牛

许多公司都对于基础架构的需求，都依赖内部独立的交付团队是否有意识，通常的表现就是：公司只针对特定的框架需求设置服务器，所用的部署实践也是多年来逐渐构建的。我们多用神灵、星球甚至飓风的命来给硬件命名，将它们看作脆弱、唯一的雪花般宝贵。然后，某个公司的阿波罗服务器宕机了。

全公司都乱套了，一时间公司内哀鸿遍野，大家都想拼命做些什么来解决问题。最疯狂的是：由于这台服务器太过关键，所有人都向它致以最深切的哀悼，整个公司都在经历“悲伤的七个阶段”。

之后他们启用全新的硬件，比之前的更加庞大快速。几个月之后，阿波罗服务器完全被遗忘了，就像没存在过一样。尽管大家都知道不久的将来还会有宙斯和阿瑞斯这样更先进的设备，但知道有这件事不代表已经做好了准备。

进入封装技术时代

讲到这里推荐大家去阅读一篇由Zach Gardner撰写的博文《Docker: VMs, Code Migration, and SOA Solved》，介绍了封装技术在Docker中应用的一些注意事项，值得一读。

坦率地说，我本人是个微软粉，但微软在封装技术领域有些落后于其它公司。在Docker发布了近三年之后，微软才跟上趟。不仅如此，在微服务的问题上 .NET社群在工具和创新方式无法与Java社群中的Netflix和Amazon公司的成果比肩。

但我仍然喜欢微软：尽管他们在这点上落后于他人，但他们发行的产品更容易上手，而且售后与支持服务更好，Service Fabric也不例外。

Service Fabric框架不仅能让开发者封装可部署代码，另外还内置了微服务的最佳实践案例。想要查看更多信息，请移步《Discussion of Architectural Styles to Mitigate Technology Shift: Microservices and Single-Page Applications》.

Service Fabric框架吸引人的原因不止于此。随着微软最近几年提出的透明和公开原则，Service Fabric框架没有被约束在Azure上，甚至突破了Windows的限制！没错，它不仅可以在本地数据库的Linux上运行，还可以在AWS上运行！更重磅的消息：嵌入其中的微服务不必再使用.NET开发，而是可以使用任何代码，随你喜欢——Java、C++或者Ruby。

我认为：这才是人们需要的领先技术，是微软的一大进步。

演示开始

有了前边的长篇大论，接下来进入正题。演示过程十分简洁，但能让你快速上手。

首先准备好工作环境

完工之后，打开Visual Studio（以管理员身份运行），新建一个Service Fabric工程，命名为ServiceFabricDemo。

不要把它保存在根目录里，因为有些依赖库的名字相当冗长，所以，默认的文件夹名加上这个文件名，整个路径名成可能会超出合法命名长度。

我们选择ASP.Net 5工程，将其命名为Web

选择Web Application Template

点击Debug，调试ServiceFabricDemo

第一次使用将花费五到十分钟调试。它会自动设置并启动Fabric集群，随后的部署将花费一分钟左右，期间无需操作

Application Running（程序运行），至此教程结束。搞定！希望大家能喜欢这份教程。

等一下！还有一些内容

找到任务栏，在里面打开Service Fabric Explorer，Service Fabric的图标长这样。

右键点击，并选择Manage Local Cluster（管理本地集群）。

之后会出现Service Fabric Explorer。

点开展开栏，在刚才的web工程下面找到ServiceFabricDemo。目前这个节点上只有这一个工程。这是无状态服务的默认行为。

本教程不涉及有状态和无状态服务的介绍，如需要请移步Service Fabric Documentation Portal

现在可以在资源管理器里关闭单独的节点，这样做是为了模拟服务出错的情况。开发者可以将失败情况拷入服务中。在Keyhole Software，我们都喜欢使用Failure As A Service以确保软件的出厂质量。

继续寻找部署了网络服务的节点，在演示里是节点1。不过，在哪个节点上加载应用要取决于运行库，实践中可能会有所不同。

这是之前部署在节点1上的一个应用，右上角有执行按钮，点击停用（重启）就会关闭这个节点。

好，现在去找之前的web应用。

找不到了，怎么办呢？

就像之前说的那样，按照默认设置的话，只会部署到一个节点上。我们对此稍作修改。
首先，再次点击之前关闭节点的那个按钮，重新启动节点。

然后返回Visual Studio，打开ApplicationManifest.xml。

现在还没配置过实例信息，如果我们点击DefaultServices => Service => StatelessService，加入实例数值“-1”。

这样，web应用将会被部署到每一个可用的节点上，对于无状态服务来说，这是很好的选择，可以将负载作最大程度地均衡。不过如果代码有泄漏，先不要这样做，修复内存泄漏再说。

再次调试程序，一旦启动并运行时，检查Explorer。注意：会花一点时间，因为会复制到所有节点上。如有断点选择跳过，这样程序才能正常加载，否则就将会陷入in build（未完成）状态。

出现这个，说明已经完工。如果现在关闭节点，仍然可以打开web应用。

这简直太棒了，一旦开发者遇到开发或维护有状态服务（跟单、金融系统等）的工作时，Service Fabric框架就会非常出彩。即使是再普通的服务开发，也能让开发者在无需修改程序架构与部署脚本的情况下，简单地根据需求对应用所需资源作出调整。

有了Service Fabric框架之后，你就有了任劳任怨的老黄牛牌服务器，随时移除任何一台都不会对公司造成任何损失。不仅能用于灾难场景，也能用于常规的设备升级等场景中。

总结

微软已经用Service Fabric框架整合了一些非常实用的工具，可用于以下场景。以下文本出自官方文档。

高可用性服务

Service Fabric框架提供了快速故障转移，允许开发者创建多个二级服务副本。如果某个节点、进程或单独的服务由于硬件或其它故障而出错，那么会有一个二级副本立即启用，替代之前的服务运行，客户几乎不会有任何损失。”

可扩展性服务

可以对某个服务进行分区，并允许在整个集群中执行状态扩展。此外可以快速创建或移除某个服务。可以根据资源需求，从几个节点的几个实例开始，快速简单地扩展到分布在很多节点上数以千计的实例。开发者可以使用Service Fabric框架创建并管理这些服务以及它们的整个生命周期。”

非静态数据的计算

Service Fabric框架可以构建数据、执行输入/输出以及计算状态密集型的应用，还能有效地协调处理计算与应用中的数据。一般来说，如果应用需要访问数据，由于需要访问外部数据缓存或存储层，总会产生网络延迟。而使用Service Fabric框架则不会有这样的延迟，从来带来更高的读写性能。

例如：某个应用要在不到100毫秒的时间内，为消费者近乎实时地进行推荐，由于需要结合数据与规则作出推荐计算，Service Fabric在这方面为用户提供的体验，无论在延迟还是性能上都很优秀，远胜于需要访问远程存储拿取必要数据的标准解决模型。

基于会话的交互式应用

Service Fabric对于在线游戏或即时通讯等需要低延迟读写的应用也很有用。无需像无服务应用那样创建单独的存储或缓存，Service Fabric可以让用户创建交互式的有状态应用。

分布式图形的处理

社交网络的发展大幅提高了人们对大规模并行图的分析需求，而快速扩展和并行负载处理的能力让Service Fabric框架自然而然的脱颖而出，方便用户构建高度可扩展的服务：如社交网络、商业智能和科学研究。

数据分析与流程

Service Fabric可快速执行读写，因此我们可以用它来构建这样的应用：1. 必须对数据流执行可靠的处理；2. 描述处理管道，必须保证可靠无损地交付到下一流程。这些应用包括需要保持数据一致性与计算可靠性的事务处理与财务系统。

特别注意：Service Fabric目前只有Beta版，尚未投入正式使用。现在可以先做好计划，等上市后再做打算。RTM版本将于2016第二季度发售。