框架是教科书，但是思考架构更有价值

相信许多开发者都学习过 SSH 和 Spring MVC，当然也有些人是从.net 和 Ruby on rails 上了解的。这些框架设计的都是如此的健壮，以至于我们在年轻时都时不时地由心赞叹设计者的严谨的设计和强大的动手能力。但是我现在认为这些框架无论多么健壮，但已经不适合逐渐趋向敏捷开发的互联网架构了。至少对年轻人而言却依旧有着教学的意义，使我们知道自己的不足。

中国后端开发从 2014 年至今，这个期间已经发生了无数的创新和巨大的变化。首先，在接口上，自一篇 2000 年称颂的 Roy Fielding 博士 [论文][1] 从美国硅谷传教至中国的中关村，越来越多的开发者开始在网站开发中使用 HTTP API。当然，由于一些历史的源由，多数的企业网站一般只用 Get 和 Post 方法接口规范。而在这之前绝大多数开发者都使用着 RPC 和 SOAP 作为接口规范。部分内容网站则使用 Webhooks 规范推送内容。随着近几年移动端开发的需求与日俱增，前端 H5 也逐渐成为了移动端开发的拿手好菜，但是原先常用的 HTTP API 似乎不尽如人意。由于手机芯片属于精简计算指令集（RISC），低功耗和内存少的限制使得用 Restful API 变得有些奢侈。于是，谷歌的开发者们就重新设计了 RPC，发布了新的 gRPC 规范；Apache 推出了 Thrift 产品；脸书的工程师们开发了 GraphQL 规范 [Swagger][2] 的项目中独立出 Open API。我相信这些 API 接口规范将会成为我们将来设计软件架构的重要一环。

在数据库方面，不再只有一种基于 DBMS 的 SQL 数据库。当然，目前这些 DBMS 的数据库依旧活跃在金融和银行的体系中，以及一些传统企业的日常工作中。但是这丝毫不影响“挑战者们”无限的创造力和非比寻常的勇气。出现了许许多多不错的 NoSQL 产品和 NewSQL 产品。比如著名的 Redis（KV 键内存数据库），MongoDB（BSON 的文档型数据库），CouchDB（Erlang 编写的文档型数据库），ElasticSearch（基于 Luence 搜索引擎的数据库）等等，具体参考 [DB-Engine][3]。这些数据库独特的设计使我们不再局限于对 mysql 和 Postgresql 的优化，或者对企业服务的依赖。比如，天眼查在人员关系上就采用了 neo4j 的图数据库（从前端界面的推测）。

而在架构上也有了微服务这耳熟能详的概念。对于这个架构，相信在 BAT 的同行应该更加了解，因为我已经拜读过很多来自他们所写的博客及其他文章。曾经福特一世凭借 T 型车稳坐了美国汽车行业龙头位置，同时，为了应对几乎垄断导致的巨大市场需求，必须采取更高效的方式来提高产品的产量。（P.S, 读过历史的同学应该知道卡内基工厂的黑历史，这是一个经典案例，我不多评价）经过一番研究，从肉联厂中引入了流水线模式。同样的微服务就是将功能低耦合，通过接口之间的调用，以中心化或去中心化的方式流水线工作。这样对于服务的开发、维护和测试都可以相对简化，并且像零件一样拆卸替换，增加了横向扩展的能力，减轻了纵向开发的成本。

框架对我们这些新人来说，仍旧是一个不错的学习资料，但是如果因为刻意照搬框架，只会使我们的思想受到束缚。所以，我倾向于在每次接触新的技术后，都能够用一段时间去沉淀这些知识，并重新构思设计。

“设计与研究的区别看来就在于，前者追求‘好’，后者追求‘新’。优秀的设计不一定很‘新’，但必须是‘好’的；优秀的研究不一定很‘好’，但必须是‘新’的。我认为这两条道路最后会发生交叉：只有应用‘新’的创意和理论，才会诞生超越前人的最佳设计；只有解决那些值得解决的难题（也就是‘好’的难题），才会诞生最佳研究。” ——Paul Graham《黑客与画家》[译文]

[1]: https://blog.csdn.net/mypages/article/details/83325223 "Fielding 博士的 REST 论文中文版（Rest 开山作品）"

[2]: https://swagger.io/ "Swagger 接口文档开发工具"

[3]: https://db-engines.com/ "DB-Engine 网站"