@sagaxu kotlin 官网的 api 文档只是 class/function 的接口文档. 但是, 前后端分离的开发模式, 后端需要提供给前端的接口文档, 不光包括 api 接口的参数是什么, 还要包括, 返回的 json 结构是一个什么样的树状结构的描述, 每个字段的业务含义的描述.
类似于这张图片描述的样子: http://loveinshenzhen.github.io/img/quick_start_api_doc.png

阿里的 rap2 我没有尝试过, 从它 GitHub 的 wiki 页面里:https://github.com/thx/rap2-delos/wiki/user_manual , 我猜测,他有些类似 Swagger, 需要用 yaml 或者 json 格式的文件, 描述和定义接口. 然后前后端都根据这份接口契约, 来进行开发.

可是, 一旦需要调整接口, 就得先修改接口契约, 然后再回头在后端改代码. 一旦后端代码修改了, 而契约没有修改, 就会造成自动生成的文档与后端实现不一致了.

关于 Swagger, SpringMVC 或者 Spring Boot 也提供 Springfox 这一工具,也是通过注解方式, 生成 swagger json 描述文件. 参考这篇文章里的描述: https://www.jianshu.com/p/349e130e40d5

因为要遵循 swagger 的标准, 所以提供了多个不同的注解. 对使用者来说, 使用麻烦,增加了心智负担.
我的框架只使用一种 @Comment 这一个注解. 并且作为接口返回的 json 结构, 也是通过定义类的结构来实现的.
在字段上通过注解描述其业务含义. 通过类的层次结构, 自动生成 json 的结构和文档描述.

在开发这套框架之前, 我也是有考虑过 swagger 的, 但是我发现 swagger 并不能帮我有效的节省时间(没有解决我的痛点), 所以才决定按照自己的思路做了这么一套专注于后端 http api 接口的快速开发框架.


相比 rap2 这类"开发接口管理工具", 我希望的状态是, 每当后端 api 接口实现的代码修改了, 文档就自动修改了. 保证其一致性. 无须像 rap2 一样, 还需要独立部署一套"开发接口管理工具". 每次接口变更, 还得先在这套"开发接口管理工具"上更新接口契约(配置 /描述), 再回头去修改后端的代码实现. (因为没有使用过 rap2, 我只是根据文档介绍里的了解做的判断, 如果不是这么使用的, 那就无视这段话吧)

@sagaxu api 接口, 通常需要返回一个 json 结构, 而这个 json 结构可能很复杂. 这个 json 结构,json 里每个字段也是需要在 api 接口文档里体现出来的. 如果仅仅是通过"侵入注释"的方式, 是很难实现的. 如果你知道有哪些注释文档工具, 可以根据代码, 把接口返回的 json 结构和字段说明都生成出来的, 可以告诉我. 我也可以学习和借鉴一下.

@sagaxu vert.x 只是一套底层的工具库, 如果你直接使用 vert.x 来实现一组后端的 api 接口给前端调用, 并且提供完好的接口文档和测试页面给前端工程师, 那你还需要做很多的工作.

需要注意的是, 在前后端分离的开发模式下, 前端与后端的开发人员是否能够进行有效的分工与合作, 能否提供完备的 api 接口文档和测试页面至关重要.

人都是有惰性的, 程序员大多数都不喜欢写文档. 尤其是, 当代码发生变化的时候, 还要回头修改文档, 真是痛苦的. 而懒于实时修改接口文档, 必然导致 api 接口文档与实现的不一致, 那么前端与后端就会因此引起沟通不畅.

而这套框架, 通过引入了 @Comment 这一个注解. 该注解可用于标注在 类, 字段, 方法, 方法参数 上, 框架会自动生成 api 接口文档和测试页面. 代码实现与文档保证一致性.

另外, 在离职的时候, 一般公司都有个工作的交接过程, 有的公司会要求开发人员提供开发文档. 有了这套框架, 直接使用现场的文档即可, 都不需要你自己写.

安利一下基于 kotlin 语言,我个人开发的后端快速开发框架, http://loveinshenzhen.github.io/#/sz_framework/introduction

我负责的多个项目, 都是使用这套框架进行后端开发的. 开发效率比 spring mvc 那套要快得多. 和 Play Framework 的类似. 不过 Play Framework 的语言是以 scala 为主, 而这套是以 kotlin 为开发语言的.

我也想知道

这个帖子会挨喷，前排围观 +1

@pabno 我才留意到你在后面的回复里, 指出是以用户表设计来当做类比场景的.
但是, 即便以设备数来说, 10 亿个设备数也是很大的数字. 考虑到 @mysunshinedreams 所说的, 对应几十个设备 ID 的情况, 会有,但是不会是普遍情况, 对应几十个设备 ID 的情况占比应该很小的. 所以我们粗略的给定一个设备的 ID 重复产生系数, 假设为 2, 那么也有 5 亿的设备. 这个设备数量已经很高了. 5 亿设备中, 假设有 1 亿个活跃设备, 每天产生 10 条数据. 每条数据假设为 1KB (因为不清楚业务类型,不清楚实际情况,这个值可能高, 也可能低了, 暂时先用这个值来描述问题), 一年产生的纯数据容量(数据进入到数据库后, 还会有索引等, 所以实际需要的存储容量只会比这更高) 约为: 100,000,000 * 10 条 * 1 KB / 1024 / 1024 / 1024 * 365 天 = 339.93 TB

所以, 真有 5 亿个设备, 是会产生海量数据问题的. 而海量数据问题的性质, 复杂度, 解决方法, 已经超过表设计这个问题范畴了.

初期,不要考虑海量数据问题. 因为, 很大概率上, 公司都不能撑到有那么多的用户量 /设备量.
如果真的遇到了海量数据问题, 那么恭喜你们! 你们项目,你们的事业已经成功一大半了.

@pabno 不好意思,我的回复是稍微带着点调侃的味道,先对你说声 sorry
虽然是带着点调侃的话,可是我想说一下技术外的问题. 先从"10 亿用户"这个数量来说. 题主在问题里给出的表设计描述: 用户表的设计是 (bigint user_id, bigint phone, varchar email). 用户是以手机和电子邮箱为用户标识的.
@mysunshinedreams 但从表的字段来说,注册的对象背后是手机号码和邮箱这种身份标识资源, 与具体设备无关.不存在一个手机对应几十个设备 ID, 因为关注的是 phone 和 email
因为现在是移动互联网,所以普通用户使用邮箱注册的毕竟是少数,我们先假设 10%的用户是使用邮箱注册,另外 90%使用手机注册. 抛开 1 亿个邮箱注册的用户, 剩下 9 亿个手机号码. 再假设人均 2 个号码(实际生活里, 绝大多数"正常用户"只会使用一个手机号码, 并且,人均 2 个号码这个数值其实已经给得很高了,这里是为了方便计算, 如果调低了,只会让计算出来的真实注册用户数更多).

回到之前的描述, 假设人均 2 个号码都注册了, 那么使用手机号码注册的人数也有 4.5 亿. (还没有把使用 email 来注册的用户算进来). 4.5 亿个用户, 大家能理解这是个什么概念吗?
如果题主所在的公司是一个小公司或者初创公司. 我认为 10 亿用户 数,根本就是个伪命题. 因为, 很大程度上, 等系统上线后, 能不能撑到 100 万的注册用户数, 都是个未知数. 所以担心一个几乎根本不可能发生的问题, 没有必要.
如果题主所在的公司, 依旧有一定的规模. 有超过 100 万的注册用户, 我觉得这个公司也应该有钱请个资深的架构师来解决这个问题(重构系统), 就像 @GDC 所说的,应该也不会来 V2 问这样的问题了.
这让我想起来多少年前业界的一个笑谈. 一帮人创业, 先用 ruby on rails 开发出产品原型, 上线. 然后融到资, 接着再招聘另外一帮 java 的人, 把 ruby 写的系统再重构到 java 上. (Twitter 还真就是这样的)

@pabno 我觉得, 你现在所处的公司应该是个初创企业(我猜的, 如果我猜错了话,这些回复内容就当做废话随便看看吧) 你其实你现在根本就不需要担心 10 亿用户这个问题. 因为到 10 亿用户, 整个系统面临的不仅仅是用户登录查询的问题. 10 亿用户, 假设 10%的的活跃用户, 那就是 1 亿的活跃用户. 这些用户在你们系统里的行为活动, 会产出大量的数据. 这已经不单单是一个用户表设计的问题了.
量变引起质变, 海量用户数据的处理,会引申出一系列的问题, 单机数据库在性能(tps/qps), 容量上不够. 需要分布式数据库, 按照业务领域进行垂直分隔, 按照数据进行水平拆分. 分库,分表,数据归档. 引入 no sql 的数据库在应用层建立索引服务, 媒体数据的海量存储, 加速访问的 cdn. Api 应用服务的负载均衡, 微服务,集群,数据容灾备份等等. 更别说, 处理海量数据所需要的云计算的云主机,带宽,存储等资源, 需要的也是流水般的费用呀.

但是, 对于一个初创公司的初创项目, 压根就不需要考虑海量数据问题. 因为初期压根就不会遇到海量数据带来的问题.
不要提前过渡设计. 一开始也不要把问题给复杂化. 不要试图做一个完美的系统. 不要考虑你几乎不会遇到的问题.

不过设备也很牛逼呀, 假设单个设备的成本是 10.00 元, 光设备他妈的也要 100 亿元. 还不算分发,部署,运维,网络通讯费,后台带宽服务费, 后台服务器,存储等费用. 这个系统真弄下来, 耗费巨大呀

哦, 才注意到, 是设备,😅

全球接近 80 亿的人, 地球上每 8 个人,就有一个人是你们系统的用户,牛逼,呵呵

推荐一下: Kite
Kite is a plugin for your IDE that uses machine learning to give you useful code completions for Python. Start coding faster today.
https://www.kite.com/integrations/vs-code/

请了解一下 写入放大（英语：Write amplification，简称 WA ）
写入放大是闪存和固态硬盘（ SSD ）中一种不良的现象，即实际写入的物理数据量是写入数据量的多倍。

不管是 android, 还是 ios 手机, 用久了后, 手机里的各种 app 应用,会产生大量的临时文件. 写了删, 删了又写.(例如各种社交 app, 在线视频, 直播等等种类的应用) 不光会在文件系统产生碎片, 而且会引起闪存的写入放大问题.
并且,很多手机品牌为了价格, 采用很多低成本的闪存方案. 这些闪存方案提供的控制芯片,不能够很好的处理写放大问题. 所以, 后面越用越慢也是必然的结果.

请勿使用技术作恶!!!
当你协助他人制作恶意欺骗诈骗钓鱼网站, 结果, 你的请朋好友不幸成为受害者.
请你反思一下,所作所为是否正确.
勿以善小而不为,勿以恶小而为之

@q937298063 我推测， 因为所有的公网过来的网络请求，都会经过阿里云的防火墙后，再转发到对应的 ECS 的内网 IP 上，而这个公网 IP 的连接数，转发速率是有限制的。
腾讯云也有类似的问题， 所以腾讯云也一样有对应的负载均衡服务。
阿里云和腾讯云提供的负载均衡服务实例，就是用在需要对外（对公网）提供大量并发，大量连接（长连接，或同时指支持的连接数非常高）的应用场景。反过来想，如果阿里云，腾讯云不对 ECS 上的网络进行限制，这个负载均衡服务存在的意义就不大了（不好卖钱了嘛）

ab -c 300 -n 500 地址
这个地址是 ECS 分配的公网地址吗？
如果是 ECS 分配的公网地址，通过这个公网地址访问，并发性能（并发数和 QPS ）是上不去的。
除非你购买阿里云的负载均衡服务（有独立的性能配置和带宽配置），通过阿里云的负载均衡服务转发请求到你的 ECS 上的 php 服务器上。

推荐程序员看的数学基础书:
程序员的数学思维修炼（趣味解读) https://www.amazon.cn/dp/B00LZNH432/ref=sr_1_5?__mk_zh_CN=%E4%BA%9A%E9%A9%AC%E9%80%8A%E7%BD%91%E7%AB%99&keywords=%E7%A8%8B%E5%BA%8F%E5%91%98%E7%9A%84%E6%95%B0%E5%AD%A6&qid=1557238712&s=gateway&sr=8-5

程序员的数学
https://www.amazon.cn/dp/B00A4H3JJS/ref=sr_1_2?__mk_zh_CN=%E4%BA%9A%E9%A9%AC%E9%80%8A%E7%BD%91%E7%AB%99&keywords=%E7%A8%8B%E5%BA%8F%E5%91%98%E7%9A%84%E6%95%B0%E5%AD%A6&qid=1557238712&s=gateway&sr=8-2

Apache Ignite
https://liyuj.gitee.io/