jerryshao

这是惊恐发作，属于焦虑症。

我自己差不多用了一年的时间才完全康复，过程也很曲折。

主要是因为作息时间不好、压力大、咖啡刺激。交感神经和非交感神经相当于一个油门一个刹车。因为外界和自身的刺激，半夜非交感神经开始踩刹车的时候，自己强行踩油门让自己清醒之类的。时间久了，这两个配合出现问题。半夜可能交感神经突然介入，其实心跳也就七八十，但是感觉 100+。就好比你马上要当着几百人上台演讲、或者遇到了危险，心脏立马怦怦跳，这是正常的交感神经介入。只不过交感神经在不正常的生活环境、心理压力和外界刺激下，或者在你失眠的时候突然介入了。

推荐你看一本书《焦虑症的自救》 https://book.douban.com/subject/35266331/

做个全面体检，证明没有任何器质性问题，是纯粹心理问题。

然后适当降低咖啡因、少熬夜。在生活和工作上找找压力的来源，调整一下。

@ryan4yin 感谢反馈！

请问你是说像 SEARCH(), SUM()之类的函数吗还是 Metrics Insights 类 SQL 的查询语句很难写？

如果能给几个查询例子就更好了！

我可以牵头看看如何改善这一块的用户体验。

*EC2 Detailed Monitoring

@ryan4yin

如果是 CloudWatch 监控指标相关功能不好用，可以举几个例子吗？

AWS 资源产生的基础设施监控指标一般都是免费的，除非开通 1 分钟精度的 EC Detailed Monitoring 单独收费。

@hlayk 可以是可以，但是大家在这里建议的是业界比较认可的做法。

如果返回 200，前端根据 code 字段做相关处理，那后端做可用性相关的监控就比较让人头疼。
不知道你们有没有对后端的 canary test，中文好像叫拨测？将来持续测试后端 api 的话，正常来说判断 api 是否成功就是使用这些 http respond code 。如果后端都是返回 200，那相关的测试也无法从 http respond code 获知是否成功，需要解析里面的自定义 code 才知道。

后端参数校验错误应返回 400 HTTP respond code 。
message 应返回有帮助性的错误信息，比如请求参数里的 XXX 字段长度不能超过 YYY 等等。
code 字段可以是自定义错误码，一个自定义错误码对应一个异常。

Retrofit 抛异常是对的，前端应该 catch 这个异常并做相应处理。
比如 catch 异常并分析 respond 是 400，打印日志，看是否需要提示前端用户参数错误或加强表单验证。
如果 catch 异常并分析 respond 是 500，打印日志，上报监控指标，配置 client 进行请求重试。

14 年来爱尔兰，确实发现信息不太畅通的问题。
这么多年也有 0086，新岛，华人志。

感觉有这样几个问题：
1. 爱尔兰华人还是少，市场小
2. 2+2/3+1 项目多，留下来的学生少。做的好也很难靠用户推荐给用户。
3. 老华人 /留学生都是上 6park，现在的学生在电脑刷论坛的少了

我的理解是这一套搭在不同地域或者同一区域的不同可用区然后前面加负载均衡。

可以自己先做一下测试，比如在一个可用区启动 2 个 2C4G 和一个 8C16G，给前面两个 50%的负载，后面一个 50%的负载。不断增加请求，看看 CPU，内存，硬盘吞吐等等指标的情况，找一下性能瓶颈再决定单机还是多机。

前两个月也可以先用 on demand 看看，太着急包年买可能会造成浪费。