一、传统开发模式

传统的开发模式基本一般是重服务端的开发方式，大部分工作都在服务端执行，然后返回到客户端（通常是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