Azure Service Fabric微服务架构

        作为一名咨询从业人员，小编大致总结了下企业上云的一些顾虑：

• 无法控制硬件（质量、维保级别、可用性均不可知）；
• 故障来临时无能为力；
• 实例扩展情况不可知，是否根据应用所需有效扩展；
• 管理服务往往比搭建服务更难，服务商是否有后门权限；
• 没有离线升级机会；
• 成本是否可控，当前服务承受的强度不可知；
• 外部访问安全问题。

        为打消上述的部分顾虑，云服务商纷纷推出了微服务平台，旨在让用户可以持续地改进应用、根据客户需求更快地交付功能/修复缺陷、规模化地建设及运维。

        传统的服务拆解是通过纵向拆解，一般分为网络层、业务层和数据层，服务扩展为横线扩展，即在每一层部署多台服务器/虚机/容器。

       而微服务则是将前中后端的功能进一步拆解成原子模块，然后组合成不同应用，而扩展就是将每一个原子模块分布式地在服务器/虚机/容器上创建实例。

        相较传统应用，微服务构建的应用虽然需要打理组件间的逻辑，各组件的开发平台还不不一，开发团队间势必有些碰擦，但易扩展、易更新，因此更适合敏捷型的业务组织，优势在于：

1. 分组件扩展：比如说一个照片共享服务，按微服务可以分为完整照片库和前置的缩略图服务两个，如果客户端访问量较大，扩展前置服务即可；后台原图调用频繁，扩展照片服务即可。
2. 适用于不同技术栈：还是前面的例子，如果不拆分照片库和缩略图服务，这个图片共享服务就需要用同一种技术栈来编译，但是缩略图服务更适合使用.NET来开发，而图片库可以选择别的技术栈，如nodejs, Java等。
3. 独立部署：拆分之后各自的版本可以更加灵活，更消除了原单体服务底层Kernel的关联性

        微软的Service Fabric架构为Azure、本地或混合云上的微服务提供了生命周期管理、高可用、容器编排、编程模型、健康监控、DevOps工具以及自动扩展等服务。目前微软自身运行在Service Fabric上的服务有：Azure SQL，文档数据库、Cortana、SfB、物联网Hub、事件Hub以及PowerBI。

        下面来举个例子吧，我们在Visual Studio中建立一个基于Service Fabric的照片共享服务。

        平台给这个程序配备有集群管理服务、故障转移管理服务、错误分析服务以及名称服务。并且按照默认的访问量分配了5个节点。

        就5节点的可用性，在主节点宕机时，服务会有约13秒左右的宕机时间。