在Service Fabric上运行微服务

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框架不仅能让开发者封装可部署代码，另外还内置了微服务的最佳实践案例。想要查看更多信息，请移步。
　　Service Fabric框架吸引人的原因不止于此。随着微软最近几年提出的透明和公开原则，Service Fabric框架没有被约束在Azure上，甚至突破了Windows的限制！没错，它不仅可以在本地数据库的Linux上运行，还可以在AWS上运行！更重磅的消息：嵌入其中的微服务不必再使用.NET开发，而是可以使用任何代码，随你喜欢——Java、C++或者Ruby。
　　我认为：这才是人们需要的领先技术，是微软的一大进步。
　　演示开始
　　有了前边的长篇大论，接下来进入正题。演示过程十分简洁，但能让你快速上手。
　　首先准备好工作环境
　　完工之后，打开Visual Studio（以管理员身份运行），新建一个Service Fabric工程，命名为ServiceFabricDemo。
　　不要把它保存在根目录里，因为有些依赖库的名字相当冗长，所以，默认的文件夹名加上这个文件名，整个路径名成可能会超出合法命名长度。