一、摘要
好大夫在线已经收录了超过69万医生信息，其中有24万医生在平台上实名注册，服务用户累计6700万。随着业务快速发展，伴随而来的系统复杂性和多样性也越来越多，我们发现原先的服务架构已经跟不上业务的迭代速度了。All-in-one发版时间过长，服务耦合在一起，一出问题很容易波及全站。2018年公司开始推进微服务拆分，由php转向java，前端开始转型node，迎来了服务快速增长的阶段，目前我们有350多个微服务，每隔几周会上线一个新服务。随着服务的逐渐增多，我们发现编织的微服务大网越来越大，面临微服务治理的挑战也越来越多。微服务治理包含范围非常广，主要有服务发现，服务注册，服务编排，服务配置，服务网关，服务监控预警，日志分析等等等等。其中遇到问题最多的是围绕服务的稳定性和可用性，比如如何快速定位问题和评估影响范围。接下来就针对服务的稳定性和可用性聊一下我们的应对措施，主要是日志分析和应用画像平台化。
二、聚焦微服务治理痛点
主要从应用，中间件的稳定性和可用性两个方面分析。解决方案：构建平台，包括日志全息分析、实时告警，应用画像、配置管理。随着业务日趋复杂，All-in-one笨重的系统很难适应敏捷开发的节奏，应用按不同的维度进行微服务架构拆分成为趋势。然而庞杂的业务系统由不同语言开发，不同团队维护，微服务治理也迅速带来新的挑战。
曾经的痛
曾几何时，几个人关在“小黑屋”排查问题的场景历历在目。记得2019年初夏，一个周五，马上就要欢度周末了，临近下班的时候，有用户反馈支付失败，紧接着越来越多的用户开始投诉，医患交流失败，很多方向的业务开发围到系统组，我们如临大敌，大家一起找个会议室排查问题。一开始我们觉得是网络抖动，因为出问题就在那一分钟内，有接口超时，有接口失败。各种查登录机器，各种猜测，最后定位到一台mq节点内存有波动，导致部分生产者被夯住。最后发现是是新加的一台mq没有切割日志，导致程序内存使用过高。从开始排查问题到最后定位出问题，足足花了一晚上。这种痛只有经历过才知道，也促进我们成长，这就是所谓成长总是痛苦的。我们开始整合中间件日志，让应用和中间件产生联动。诸如此类的还有很多很多。。。
我们面临的问题到底是什么
如何快速定位故障？告警事件爆炸，如何判断业务方异常，还是中间件异常，亦或是某个机器异常？
如何追踪调用链路？一条调用链路涉及几十个应用，异步处理的请求如何溯源？？
Comments