复杂业务开发过程中的痛点
我们在进行复杂业务开发的过程中，有以下几个常见的痛点：
-
时间紧、任务多、团队⼤、业务增⻓快，如何还能保证架构稳定可靠？
-
研发⽔平参差不⻬、项⽬压⼒⾃顾不暇，如何保证质量基线不被突破？
-
公司有各种⼯具平台、SDK、最佳实践，如何尽可能的在业务中使⽤？
互联网业务研发的特点是“快”、“糙”、“猛”：开发节奏快、质量较粗糙、增长迅猛。我们能否做到“快”、“猛”而“不糙”呢？这就需要有一些技术架构来守住质量基线，在业务快速堆砌代码的时候也能保持技术架构的健康。
在大型项目中，我们也经常会短时间聚集一批人参与开发，很显然我们没有办法保证这些人的能力和风格是完全拉齐的，我们需要尽可能减少“人”在项目质量中的影响。
公司内有大量优秀的技术平台和工具，业务中肯定是希望尽可能都用上的，但又不想付出太多的使用成本，必定需要有一些技术手段让业务与公司基础设施无缝集成起来。
很自然我们会想到，有没有一种“框架”可以解决这个问题，带着这个问题我们探索了所有的可能性并找到一些答案。
以史鉴今：从服务框架的演进历程中找到规律
服务框架进化史
服务框架的历史可以追溯到 1995 年，PHP 在那一年诞生。PHP 是一个服务框架，这个语言首先是一个模板，其次才是一种语言，默认情况下所有的 PHP 文件内容都被直接发送到客户端，只有使用了 <?php ?> 标签的部分才是代码。在这段时间里，我们也称作 Web 1.0 时代里，浏览器功能还不算强，很多的设计理念来源于 C/S 架构的想法。这时候的服务框架的巅峰是 2002 年推出的 ASP.net，当年真的是非常惊艳，我们可以在 Visual Studio 里面通过拖动界面、双击按钮写代码来完成一个网页的开发，非常具有颠覆性。当然，由于当时技术所限，这样做出来的网页体验并不行，最终没有成为主流。
接着，Web 2.0 时代来临了，大家越来越觉得传统软件中经常使用的 MVC 模式特别适合于服务端开发。Django 发布于 2003 年，这是一款非常经典的 MVC 框架，包含了所有 MVC 框架必有的设计要素。MVC 框架的巅峰当属 Ruby on Rails，它给我们带来了非常多先进的设计理念，例如“约定大于配置”、Active Record、非常好用的工具链等。
链接：https://pan.baidu.com/s/1y4PcAIwc4RtNPFqyvuYk6g
提取码：hk8v
大家一起努力学习，加油。