最大问题是 Http 的 Code 码是 3** 4** 2**都是有规定含义的，浏览器表现也不同，用这个一些自定义的返回很难说明。前后去过的两家公司都是统一返回 200，内部状态码判断 msg 说明错误描述 value 返回值

这项目不小的，至少 7 位数，范围 1KW 左右吧。
1.首先采集设备+服务器硬件成本你要考虑。
2.后期维护要有时间限制，无限制就是大坑。这块后期维护也是成本，包括安装对接。
3.这边还有个主要问题，这种数据实时上报，最后会越来越大，出分析和统计信息可能需要用到大数据平台，最好了解下数据的存储时间，如果 1 年以上，你可能要用大数据分析。。保存 3 个月就自动把数据备份后清除。要不然用半年就要蹦

a.纸币消失(未来 200 年内没可能，国家不允许)

b.纸质书消失(未来也没可能，不会全部消失，只会减少)

c.自动驾驶普及率达到 50%以上(2050 年没可能，技术哪怕解决，法律存在道德死节，两个人撞谁问题？)

d.月球旅行正式启动(✅ 平民化没可能)

e.进入 8G 时代(✅ 如果改名也算的话)

f.电脑硬盘容量起步 100T(没可能，机械硬盘寿命最高可超过 10 年，2040 年要淘汰掉所有 500G 硬盘都不现实)

g.大学普及(✅全民不可能，普及率到较高程度可能，毕竟新生儿减少招生增加)

h.攻克癌症(没可能，生命科学还处于原始阶段，相对于科幻片)

i.机器人进入寻常百姓家(没可能，现代 AI 就是统计学。如果小米扫地机器人算是的话，那有可能。。。)

j.人均寿命达到 99 岁(没可能，发展并不一定平均致富，还可能导致极端贫穷和极端富有，富有有富贵病、贫穷有贫穷的病)

k.房价回到 2000 年(没可能，国运不差就没可能)

l.中国男足打入世界杯 8 强(没可能)

m.中国男篮打入世界杯决赛(没可能)

n.贫穷消失(没可能，1 万年也没可能)

o.回帖的人都成为亿万富翁(✅)

比较靠谱的还是码云+CDN,Github 比较慢。你网站要是 512 字符大小，那可以用 CDN 返回 TEXT 文本。。。理论上一个 CDN 服务器就够了，逃~~

动漫这个需要好的剧本、音乐、画面、导演、特效、配音 那个少了都会给人垃圾的感觉。中国动漫几乎每个都有点问题。
这几个动漫我觉得无明显短板，或有明显长处，可以说是中国动漫之光了。
1.刺客伍六七(打斗最好的、治愈、剧情优秀)
2.罗小黑(萌)
3.成龙历险记(剧情太好)
4.灵笼(剧情好、题材很新颖，终于不是升级打怪了)
5.镇魂街(第一部结局加分太多)
6.非人哉(萌 温馨)
7.疯味英雄(当年觉得这是最好的动漫，剧情优秀)
8.尸兄(题材特别)

出租发生违法刑事责任、交通事故你都有要负主要责任，三思。

@402124773 说的对，这个就是当时压力大，你现在压力也很大，会反复做梦梦到。主要是焦虑、压力大、生活三点一线。

分母分母

还有个叫群星，星际版文明

文明 5-6，回合制、建造类、对抗都满足你，就是肝疼

外界都不会提供这种吧，信息精确到人都是违法的。想制作自己用的话，建立一个特殊性比较高的个人关键字表，比如***学校 ***，或者社交网路的账号名。通过搜索引擎爬取，但准确性不高。。。

早晨 9:30 上班，中午 11:50-2:00 午休 晚上 9 点下班 周末双休 算是 995 吧

建议：“刚需就买”，是因为你只有一套房子，被套牢后要生活和住，没法转卖，这个为国接盘是最稳的。但是对于刚需家庭，则是个灾难，六个钱包掏空了，贷款每月还 1 万多，但是房子还在贬值，经济形式不好、家人有点生病什么的、孩子上学问题、物价问题都可能会导致家庭可支配收入濒临崩溃，房贷一旦还不上就直接永无翻身之日了。
反而投资没有问题，我拿 1000 万投资，下跌我止损 800 万回来，或者持有也没问题。
比刚需买房更可怕的是抵押+高杠杆，贷款还不了，给银行一堆房子。。。GJ 最讨厌的就是这批人

@orzorzorzorz 现在大厂基本都是社招为主，校招要的基本也是起始 P5-P6，要求一般都是有项目经历或者名校加成，说白了就是来了就能干活的。
@s17chucc 2 年 P7 基本不可能的，除非你行业影响力非常的大。阿里那边要求 P6 一般要 3 年经验，你连投 p6 都有风险。。。

@suikatw 以前一般用服务总线，其实就是现在微服务的雏形。你说 BAT 大项目，在洪荒时代，也不是一个项目跑的。。。他们也会划分项目的，那时候一般比较粗糙，没有注册中心、调用链监控、RPC 模块、协议一般也都是 HTTP，关于重试和降级策略一般都是自己写在项目里，把这些抽离出来就是 RPC 框架。有些说的也对，最最开始的确一个项目，京东以前还是 Asp.net 。。。然后前面挂负载均衡，报错有时候你还能看到 Asp.net 把异常堆栈抛到前端。。。

至于你说分目录，优点不说了，说缺点：
(1)随人员变动、项目扩大，你很难维持现有的结构。git 冲突 版本管理也是很难解决的问题。比如我写完了这个模块要上，但是别人需要依赖前一个版本，你需要等。你用 Dubbo 可以通过 group version 解决，可以同时支持多版本开发。
(2)只要有修改别人代码的可能，就一定会发生。所以专注自己系统，不会给多余的权限
(3)一个简单 BUG 的修改都将导致服务重新发布，并且编译和发布时间成本巨大，在发布时，容易造成故障，压力激增
(4)这种结构容易造成雪崩，一般的，比如物流系统故障，订单已经下达，可以通过 MQ 重试机制保障物流恢复后系统自动恢复。而单点一旦崩溃，将导致整个系统不可用，数据无法进入，也不可能恢复。
(5)项目实践会告诉你，随人的增加沟通成本会越来越大，最后新增加的人的效率将不足以弥补沟通成本。解决方式就是系统拆分，专注自己的系统。
(6)至于机器占有资源问题，那是因为你预估有问题，没有计算你需要的 QPS 和机器资源。估计都是差不多直接上去。另一方面，当系统使用人数增加后，比如看东西的人很多，但是买的很少，那我可以扩容商品模块，而不需要对订单系统进行扩容，系统大了资源消耗反而降低。
(7)维护成本增加是必然的，但可以通过技术去解决 HSF、Dubbo、SpringCloud，以及之后的服务网格都是在解决成本问题
(8)服务不是无限拆分的，一般系统确定时，系统设计这个阶段要占用 50%时间，划分领域。要注意事务尽量属于自己所属领域，避免跨服务的分布式事务以及跨库事务。

没有最完美的架构，具体问题具体分析，要不然要这么贵的开发和架构干嘛：
(1)你要是外包项目或者中小项目，或者人数少，那就一个项目跑呀。
(2)如果你项目开始就定位比较大，比如目标是全中国用户，那开始架构时就应该考虑到微服务的形式
也可以渐进式演化，BAT 京东 这些最初都是一个项目跑的，有钱时再慢慢变成了领域模型内切分，各个服务高内聚，低耦合，用 MQ 解耦合以及填谷消峰。

假如你把阿里所有业务写到一个项目里，项目大小 300G，项目占用内存 300G，加载字节码时间 1 小时。。。你感觉吓人不。
还有随着项目规模增大，人员投入和项目效率会呈现反比，划分微服务有利于扩容、维护、和推迟这种情况到到来。当然这是建立在你项目复杂，并且开发人员很多的情况，要是外包或者很少开发人员，就是应该写在一个项目里。

直接问多少钱呀，先付 30%-40%，然后做到一定程度付 40%，最后交接源码付 20%。如果说免费帮忙，那对方也应该直说，你有空交情好帮帮忙也可以的。下次你有重要的事情找他帮忙，他就不应该拒绝，这叫人情世故。

问题这玩意做出来后，一批人已经受益了，后续继续维护对 KPI 没什么帮助