标签：架构 数据库 教科书 接口 开发 API 开发者 思考 设计

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

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

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

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

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

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

标签：架构,数据库,教科书,接口,开发,API,开发者,思考,设计
来源： https://www.cnblogs.com/DisonTangor/p/14589448.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。