好大夫在线技术团队
好大夫在线已经收录了超过69万医生信息，其中有24万医生在平台上实名注册，服务用户累计万。随着业务快速发展，伴随而来的系统复杂性和多样性也越来越多，我们发现原先的服务架构已经跟不上业务的迭代速度了。All-in-one发版时间过长，服务耦合在一起，一出问题很容易波及全站。年公司开始推进微服务拆分，由php转向java，前端开始转型node，迎来了服务快速增长的阶段，目前我们有多个微服务，每隔几周会上线一个新服务。随着服务的逐渐增多，我们发现编织的微服务大网越来越大，面临微服务治理的挑战也越来越多。微服务治理包含范围非常广，主要有服务发现，服务注册，服务编排，服务配置，服务网关，服务监控预警，日志分析等等等等。其中遇到问题最多的是围绕服务的稳定性和可用性，比如如何快速定位问题和评估影响范围。接下来就针对服务的稳定性和可用性聊一下我们的应对措施，主要是日志分析和应用画像平台化。
1聚焦微服务治理痛点主要从应用，中间件的稳定性和可用性两个方面分析。解决方案：构建平台，包括日志全息分析、实时告警，应用画像、配置管理。随着业务日趋复杂，All-in-one笨重的系统很难适应敏捷开发的节奏，应用按不同的维度进行微服务架构拆分成为趋势。然而庞杂的业务系统由不同语言开发，不同团队维护，微服务治理也迅速带来新的挑战。
曾经的痛曾几何时，几个人关在“小黑屋”排查问题的场景历历在目。记得年初夏，一个周五，马上就要欢度周末了，临近下班的时候，有用户反馈支付失败，紧接着越来越多的用户开始投诉，医患交流失败，很多方向的业务开发围到系统组，我们如临大敌，大家一起找个会议室排查问题。一开始我们觉得是网络抖动，因为出问题就在那一分钟内，有接口超时，有接口失败。各种查登录机器，各种猜测，最后定位到一台mq节点内存有波动，导致部分生产者被夯住。最后发现是是新加的一台mq没有切割日志，导致程序内存使用过高。从开始排查问题到最后定位出问题，足足花了一晚上。这种痛只有经历过才知道，也促进我们成长，这就是所谓成长总是痛苦的。我们开始整合中间件日志，让应用和中间件产生联动。诸如此类的还有很多很多。
我们面临的问题到底是什么如何快速定位故障？告警事件爆炸，如何判断业务方异常，还是中间件异常，亦或是某个机器异常？
如何追踪调用链路？一条调用链路涉及几十个应用，异步处理的请求如何溯源？
如何评估应用容量？机器资源配比多少合适，产品推广落地页如何规划各应用容量？
如何分析应用潜在风险？应用慢接口，循环调用，依赖不合理，找出潜在的风险SQL？
应用的可用性和稳定性越来越重要，如何降低排查问题的成本越来越重要，我们需要一双眼睛帮忙观察，一个大脑帮我们分析。
如何衡量服务的稳定性和可用性？衡量服务稳定性，首要任务就是寻找合适的SLI，设置合理的SLO。选择衡量的标准至关重要：监控项太多，图表看不过来，出问题了不知道看哪个图表，大部分时候一出问题就蒙圈，能查问题的也就那么几个人。因此指标设计原则一定要精简精简直到无法精简。配合全局画像让大家一眼就能知道哪个环节出了问题。我们主要参考的是《Google的SRE运维揭秘》，和借鉴蘑菇街赵诚老师的经验，从以下五个方面设置SLO：
应用的容量；
可用性；
时延；
错误率；
人工介入次数。
还有花哨的图表也只是辅助，大原则还是监控告警明确，快速定位出异常应用或故障节点，尝试自动故障转移或及时止损，最后通过分析画像或分析日志寻找根因。
我们来一起看一下这五条*金法则是如何指导我们设计SLO的：
这五条法则是指导意见，希望能帮助大家。
2最初的愿景平台构建最初的愿景，主要是随着微服务的推进，服务稳定性越来越重要，服务间调用出的问题越来越难以定位，排查的次数多了，各种工具脚本/Dashboard/小系统越来越多，这些经验很难传承，定制化高，推广成本大，更新迭代也不及时，普及度也是非常的低，能查问题的就那么几个人。
为了提高效率，面向全公司开发、测试全员，因此我们开始打造服务治理平台：
方便开发快速定位问题；
风险前移，对潜在风险生成任务，打造开发-测试-线上验证的闭环，后面会重点介绍；
打通数据流，告警与画像结合，能大大提高排查效率；
配置统一管理，设置熔断限流，配置故障转移策略，设置告警阈值，处理中间件事件等等，让开发能有一个统一的平台进行操作。
3平台化演进过程我们服务治理平台化演进，也经历了：人工-工具化-系统化-平台化：
1、调研应用层、中间件的稳定性和可用性，是我们