开发一个应用，然后部署运行，并在需要的时候对其进行扩展，满足不断增长的用户需求。这样的做法想必你已经耳熟能详了。过去几十年来，几乎所有应用开发者和运维人员的日常都是这样。
这种方式开发的程序也叫单一式（Monolithic）应用，需要将整个程序的所有功能作为一个整体运行在一个或多个服务器/虚拟机/容器中，并以整体的方式对整个服务器/虚拟机/容器进行扩展。
但是，你想看到的「但是」终于出现了。
这种方式开发的应用，内部不同组件和分层之间是紧密耦合的。简单来说，一个应用中可能包含不同功能，例如验证用户身份、接受用户请求、处理请求、返回处理结果……所有功能都由不同组件负责，所有组件都紧密「团结」在一起。
这就导致我们无法单独对其中的某个组件进行缩放，只能以整体的方式进行扩展整个应用，可其他组件也许并不需要扩展啊！
此外如果要对某个组件进行更新或升级，为确保整个应用能在升级后正常运行，还必须对其他所有组件进行充分测试，那么整体的应用升级工作就且等着吧……
「不折腾不舒服斯基」的聪明人开始考虑：如果将这些组件拆分成单独的「构建块」，应用的开发者只需要根据具体需求，选择所需构建块，然后搭建出自己需要的应用呢？
呐，微服务「积木」请收好，需要啥应用自己随意搭吧
这就是目前业界流行的微服务（MicroServices）应用设计方式了。
这种方式会将单个功能分隔成小规模的服务，这些服务也运行在服务器/虚拟机/容器中，每个服务可单独进行测试、版本控制、部署和缩放，不同服务之间可通过标准协议和妥善定义的接口彼此通信。
举个形象的例子：每个微服务可以看作一块「积木」，分别承担不同的功能，例如上文提到的身份验证、请求处理、结果返回等。而开发者可以根据具体需求选择不同的「积木」，通过标准的协议和通信接口连接在一起，然后，一个云应用就这样开发完成了！
相比传统的单一式应用，微服务应用具备很多优势。例如，组成一个应用的任何微服务都可以按需更新、升级、调整和缩放，借此更快速地为应用提供新的功能。此外开发者可以根据每种微服务的具体需求和特征，选择最适合的语言来开发不同的微服务，并用这些微服务搭建出最终的应用。
在 Service Fabric 的帮助下，用户可以进一步简化基于微服务的应用程序部署和生命周期管理：
-
快速上市：开发者无需考虑基础架构可靠性、可伸缩性或性能延迟等问题，可将重点放在创建为应用程序增加商业价值的功能上。
-
灵活选择体系结构：按需创建无状态或有状态的微服务，为复杂的低延迟数据密集型方案提供支持，并将其扩展到云端。通过这种方式构建的应用，不仅可以运行在 Azure 云端，也可以运行在本地，支持以 Windows 或 Linux 作为平台，甚至可以跨越不同环境构建混合式应用。
-
灵活性：借助微服务应用实现持续集成和持续开发实践，并加速新功能到应用程序的交付。
-
Visual Studio 集成：通过 Visual Studio 工具和命令行支持，开发者可针对单独部署、测试部署和生产部署快捷并轻松创建、测试、调试、部署和更新其 Service Fabric 应用。
Service Fabric 已成为微软自己的一项基础性技术，基于此技术，我们可以运行 Azure 核心基础结构，并已成功运用在 Skype for Business、Intune、Azure 事件中心、Azure 数据工厂、Azure Document DB、Azure SQL 数据库以及 Cortana 等微软服务中。
一起体验 Service Fabric 的犀利之处吧
目前我们可以在 Windows 和 Linux 平台上进行 Service Fabric 应用开发。
首先需要准备好开发环境：Windows 平台| Linux 平台。
随后，即可试着开发你的第一个 Service Fabric 微服务应用程序了。
你可以在 Windows 上用 C# 开发，或者在 Linux 上用 Java 开发，或者也可以在 Linux 上用 C# 开发，还可以将应用部署到本地群集上。
就是这么灵活，就是这么任性！