规范化及工程化

规范化及工程化

渐进增强和优雅降级

• 渐进增强 ：针对低版本浏览器进行构建页面，保证最基本的功能，然后再针对高级浏览器进行效果、交互等改进和追加功能达到更好的用户体验。
• 优雅降级 ：一开始就构建完整的功能，然后再针对低版本浏览器进行兼容

互联网架构演变

一体架构

在计算机软件发展早期，一般桌面软件都是采用这种架构，不管是界面还是业务处理还是数据处理都放到一个包中。这种其实谈不上架构，但也可以说是很好的架构，因为它足够简单。

MVC

随着浏览器的出现便产生了 web 应用，web 应用的特点是界面部分是显示在浏览器中，服务处理是在服务容器中的，页面显示一般用 css+js+html 技术来处理，而后端可以用 java、php 等语言，这就产生了前后端分离。对于 web 系统，一体架构难以满足前后端分离的开发需求，因而便产生了 MVC 架构。

MVC 代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。

• Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。
• View（视图） - 视图代表模型包含的数据的可视化。
• Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。

MVC 除了解决了前后端分离问题，还引入了一种全新的开发模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，使得整个应用层次更加分明，而且各个层次之间不但减低了耦合性，还提高了各个层次的可重用性。

但随着应用规模的不断扩大，应用模块不断增加，整个应用也显得越来越臃肿，维护起来也更加困难，因此便又产生了多应用架构。

多应用架构

多应用架构很简单，就是把原来的应用按照业务特点拆分成多个应用。比如一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等，我们可以把他们独立出来形成一个个单独的应用。多应用架构的特点是应用之间各自独立 ，不相互调用。

多应用虽然解决了应用臃肿问题，但应用之间相互独立，有些共同的业务或代码无法复用。

分布式架构

对于一个大型的互联网系统，一般会包含多个应用，而且应用之间往往还存在共同的业务，并且应用之间还存在调用关系。除此之外 ，对于大型的互联网系统还有一些其它的挑战，比如如何应对急剧增长的用户，如何管理好研发团队快速迭代产品研发，如何保持产品升级更加稳定等等 。

因此，为了使业务得到很好的复用，模块更加容易拓展和维护，我们希望业务与应用分离，某个业务不再属于一个应用，而是作为一个独立的服务单独进行维护。应用本身不再是一个臃肿的模块堆积，而是由一个个模块化的服务组件组合而成。

微服务

微服务有两个核心：

• 微：服务的粒度要细，即服务要细化到 API
• 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)

微服务的实现：

微服务的关键是服务网关，要做微服务，先定义微服务需要具备的特点。服务需要再细化成 API（服务接口——>服务 API）。

• 每个服务由一组 API 组成
• 以 API 形式对外提供统一格式的服务
• 使用者无需任何配置，直接调用（http）
• 完整的 API 文档
• API 服务安全可靠稳定