后端资源精选GOLANG后端架构程序员

服务端系统的实战积累

2016-11-06  本文已影响337人  imnx
笔者自入职我司有一年了,并有幸参与我司后端系统的一些基础服务开发和基础库的编写。这一年多的开发实践,踩了不少坑,也积累了一点实战经验。笔者主要结合实际工作中的积累或者是踩过的坑,谈谈如何构造更高可用、体验更好的web后端系统,希望能抛砖引玉。
1.高可用
2.高性能

高性能体现在两个方面,一个是低延时,一个是高并发。怎么做到呢?

3.易扩展

扩展性,对业务服务器来说,一般来说主要就是尽量做到无状态,如果确实有状态数据,可以放到更高可用的系统里,比如zookeeper、redis等,笔者之前参与开发的小文件系统就是将存储节点的相关元数据放到zookeeper里,这样调度节点就非常轻量级接近无状态。另外就是服务需要支持健康检查、自动注册和发现,比如rpc server可以直接注册到zookeeper实现自动扩容等等。

4.合适的架构

没有最好的,只有最合适的。在技术选型上也是如此。比如落地存储有些写量大的用hbase还是mysql呢?如果没有牛x的hbase维护还是用mysql吧。又比如cache集群用官方的集群还是tweproxy代理呢,还是超级client,得看公司运维的水平或者人力投入。再比如要不要做cache,要看是否有很高的命中率以及对数据的实时性要求,或者缓存更新通道是否稳定等等,当然一般这些是要解决来满足cache的。还有诸如机房容灾要不要做,是做成双主还是一主一从,数据库分表是哈希硬编码还是使用中间件等等,总之,技术选型一定要考虑到业务场景(业务需求)、运维资源和水平、开发投入、稳定性和扩展等各方面,一味的追求牛x的架构不一定合适。

最后希望以“监控”这个点做个结尾。作为合格的后端码农,每周几次的check list是非常有必要的。我们监控平台主要有两块,一个是dapper,可以看到某次请求整个链路的追踪,非常精确。一个是promtheus,从多个维度的比如作为server端同时作为client端的各种时延、请求量、错误码分布,以及进程内部状态等等。尤其关注毛刺、压力增长趋势等等。坚持做好check list,能很大程度上发现系统的各种潜在问题。
上一篇 下一篇

猜你喜欢

热点阅读