高负载微服务架构学习

师夷长技以自强
– 魏源 曾经曰过类似的话

从高负载微服务系统的架构演进之路所学习到的

文章中提到的产品是：负责30w并发用户的视频传输工作，每小时传输300TB的内容，每分钟5TB的并发数据传输。

从文中学习到以下几点设计理念，虽然有些是以前项目中就用过的，但是在此次学习中，可能有些更好的改良方法一并记录下来，帮助加深印象：

监控

尽早进行统一日志规划。

业务流程增加流程监控，可以用tweet的Zipkin 监控每个流程的执行状态，再结合OpenTracing，就能够监控到一个完整的业务流程走势

日志系统有很多种方法，市面流行的Elasticsearch、Logstash 和 Kibana（ELK）很不错，只需要简单的配置，就能够满足初期的系统监控使用。

服务的自动伸缩：

独立服务：最方便处理，伸缩仅与服务的数量相关，但是需要压测得出规格。

服务依赖了外部的资源：比如使用了数据库的服务，数据库有它自己的容量上限。如果系统性能出现衰退，就进行告警，对流程进行评估分析，然后进行架构优化或者资源调整，提升整体性能。

服务受到外部系统的牵制：比如微信api每分钟允许的请求次数是500次（举例），需要考虑到这些限制规格。

其他

每一个度量的指标，确保其有意义

不要求在半夜跑去修复的问题，就不算是一个告警。是警告，可以当成一般的问题来处理。