一、传统开发模式

    传统的开发模式基本一般是重服务端的开发方式，大部分工作都在服务端执行，然后返回到客户端（通常是HTML）。以Asp.net MVC为例，如下图：

    

 

    #1 根据请求的路由定位到对应的Controller的对应的Action。

    #2 执行相关逻辑，得到结果Model（也可能没有Model，如直接返回View）。

    #3 定位并加载对应的View（也可能没有View，如返回TextResult，JsonResult等）。

    #4 在服务端通过Razor引擎把Model和View绑定起来生成最终的返回结果（一般是HTML），返回到客户端。

 

    缺点：

    #1 职责不明确，要求工程师对前后端技术都要了解一点，有的甚至是后端工程师同时兼顾前后端。

    #2 随着不同终端(Pad/Mobile/PC)的兴起，对前端的要求越来越高，同时兼顾前后端的工程师开始感到乏力。

    #3 前端工程师必须使用后端工程师的IDE，如Visual Studio。不用的话，又会产生集成的工作量。

    #4 应用开发流程繁琐，如下图：

    

 

二、前后端分离 - 大前端时代

     随着传统的开发模式的缺点日益明显，以及前端技术与框架的发展，逐渐形成了前后端分离的开发模式。加上Html5，Css3，混合式开发技术的发展，更是把前端开发推向了一个百花齐放的大前端时代。前后端分离的交互大概如下图所示：

    

 

    #1 服务端响应请求返回结果（一般是json或xml）。

    #2 客户端接受到返回结果，反序列化成JS Object，和Html Template进行双向绑定。

    #3 Object的变化会引起View的变化，View的操作可以改变Object。

    #4 Controller托管着Object，View可以调用Controller的Event，然后给服务端发送请求。

 

    实现前后端分离的前端框架（如Angular/Angular2，Vue/Vue2，Durandal，Webix-Jet等）一般都会包含三个重要组合部分：路由、模版、绑定。

    我大概在2011年开始尝试前后端分离，但当时上述提到的框架还没被发掘出来，只有一个双向绑定的框架knockoutjs。因此，我当时做了两种尝试：

    #1 纯前后端分离：Asp.Net MVC（仅返回json） + html + knockoutjs + requirejs + ajax。

    #2 伪前后端分离：Asp.Net MVC（返回json以及无对象绑定的view） + knockoutjs + requirejs + ajax。

    之所以会有第二种方案是因为我想使用MVC的路由以及它的母板（Master Page）机制，目前的框架基本都提供了母板机制。

 

    前后端分离的通讯一般都使用ajax，少部分使用form表单，服务端接口建议使用RESTful的风格：

    

    API表示资源或领域，Method表示行为。

 

    优点：

    #1 前后端工程师职责分明，后端可以更加关注后端技术，前端可以更关注前端技术。

    #2 前端工程师可以按自己的喜好来选择IDE（WebStrom，HBuilder， Sublime等），而不需要了解后端工程师使用的IDE。

    #3 服务端的职责只负责数据处理（接收请求返回json），技术选型多样化，可以是.net， jsp， php，nodejs等。

    #4 服务端作为一个数据中心的角色，可以服务多种应用，如桌面程序，web，手机app等。

    #5 可以更好的使用浏览器缓存，静态的html和js加载一次后会存在浏览器缓存中。

    #6 应用开发流程更简洁高效（可并行），如下图：

    

 

    挑战：

    #1 对ajax的使用要求更高，目前很多前端工程师没有关注到这一点，如promise机制。

    #2 基于ajax的通讯经常要解决跨域问题。

 

三、微服务架构

    以上两种开发模式都是单体架构，它们能够很好地应对简单的业务系统。但是随着业务的扩张，功能的不断增加，单体架构面临着越来越多的挑战：

    

 

    #1 维护成本增加

         a. 团队越来越大，相应的沟通成本、管理成本、人员协调成本显著增加。

         b. 引起缺陷的原因组合多，导致分析、定位、修复缺陷的成本响应增高。

         c. 在自动化测试机制不完善的情况下，易导致“修复越多，缺陷越多”的恶性循环。

    #2 交付周期长

         代码编译、检查，运行测试、构建、更能验证等，反馈周期变长。

    #3 新人培训周期长

         对于新加入团队的成员，需要花更多的时间了解熟悉业务、配置环境、熟悉代码。

    #4 技术选型成本高

         单体架构倾向于采用统一的技术平台或方案来解决所有问题。

    #5 可伸缩性差

         a. 无法按需伸缩。

         b. 资源有效利用率低。

    #6 构建全功能团队难

         应用程序的复杂结构也会逐渐映射到研发团队的结构上。

 

    微服务架构（Microservice Architect）：

    #1 微服务架构是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

    #2 每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。

    #3 每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

    #4 另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应更具业务上下文，选择合适的语言、工具对其进行构建。

    

 

    本质特征：

    #1 服务作为组件

    #2 围绕业务组织团队

    #3 关注产品而非项目

    #4 技术多样性

    #5 业务数据独立

    #6 基础设施自动化

    #7 演进式架构

 

    优势：

    #1 边界性

         a. 业务独立

         b. 功能耦合度低

    #2 独立性

         a. 独立部署

         b. 按需伸缩

    #3 技术多样性

         a. 使用合适的语言或者工具

         b. 使用合适的数据存储

 

    挑战：

    #1 分布式系统的复杂度

         a. 网络因素（带宽、超时）

         b. 数据一致

         c. 可用性

    #2 微服务测试

         a. 测试策略

         b. 自动化测试

    #3 运维成本高

         a. 环境配置

         b. 部署

         c. 监控

    #4 微服务的依赖管理

         a. 版本管理

         b. 服务依赖

         c. 服务治理 

 

    展望：

    后续有机会的话，我会写一系列关于.Net Core如何与Srping Cloud集成的文章。

 

    说明：

    本文部分内容来自王磊的《微服务架构与实践》和infoq发表的文章：

    解析微服务架构（一）单块架构系统以及其面临的挑战

    解析微服务架构（二）微服务架构综述

原文地址:http://www.cnblogs.com/Erik_Xu/p/6241359.html

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com