本篇论述分布式系统架构设计开发中，如何测量评估远程服务节点的资源消耗与运行状态。“测”的意思是测量、衡量。“估”，是估算、评估。通过“测估”的方式，既可以衡量远程服务节点的性能健康（如：IO吞吐量和磁盘内存消耗度），又可以评估服务节点的稳定性和业务处理状况。
在分布式系统架构设计开发中，如果想要根据各种业务系统的运行情况和用户使用情况，进行相应改进和优化，一定要全方位收集各个服务节点的运行信息，分析评估各个业务系统节点的运行状况、负载压力等信息，制定出全面准确的优化改进方案。如果对各个系统节点的衡量不够详细全面，就不能辨别出各个服务节点的繁忙情况和业务吞吐量；如果对系统真实运行环境的评估不够全面精准，就不能分析出潜在的内存泄露、流程问题、业务积压等情况。
怎样进行服务节点的衡量评估呢？比较通用的方法是：估算各个服务节点的内存和磁盘大小和IO消耗占比。包括衡量和计算：磁盘使用率是多少？TPS和QPS分别是多少？服务资源的分配限制是多少？哪些服务是内存占比大？哪些服务是磁盘占比大？
还要进行各个服务的综合对比：服务是热点密集使用，还是偶然间接使用？哪里需要缓存，哪里需要事务？哪些服务适合方便扩展，哪些服务需要做高可用方案？核心系统和周边系统，哪些是核心业务系统密集通信调用的流程，哪些是辅助调度系统，需要通过MQ来解耦处理的？哪些服务节点需用实时全面监控，哪些服务需要周期性状态获取的？
还要观察评估整个系统架构的组成关系和运行演化情况，哪些是不稳定和容易连锁影响的功能，哪些是用户密集操作的业务点？哪些是内存消耗较大的业务操作，哪些是需要重点监控日志的流程？观察各个服务节点之间的关系，看哪些节点适合做主备方案，出了问题可以方便切换；哪些服务组件是需要做分布式负载的，能够抗住巨大的并发流量。
也可以从用户的角度去思考系统与用户之间的关系，以及将来可能带来的变化和问题。哪些服务对用户的体验的平滑无感的，哪些服务是需要并发排队，需要用户等待的？哪些服务依靠前端动效策略来帮助后端减轻负载的，哪些服务是需要用户校验验证的？通过采集分析用户在前端的操作习惯，分析哪些前端体验是用户喜欢的，操作顺利的，哪些操作是用户困惑或者厌恶的？通过多个角度的分析思考，进行全面充分的权衡估测。
在进行测量评估的时候，一定要从多个场景，模拟不同的情况，对系统进行测试。比如：在系统最繁忙的时候，去测量整个系统流程的执行情况和节点IO状况，测量出系统的最大吞吐量；选择网络最不稳定的情况下，去测量每个请求响应，以及界面加载顺序的时间间隔，找出用户无法忍受的延迟阀值；模拟服务节点间接性宕机的情况，观察各个服务组件的切换和处理反馈，收集受影响的关联系统的情况，去测试整个流程和服务响应是否能够降级持续服务。所以，一定要从各种极端场景，去深入的测量系统节点的运行状况，估算出适宜的应对处理方案。
所有的系统改进和架构扩展，都适合使用“测估”的方法来进行评估规划。有的系统庞大稳定，有的系统简陋崩溃；有的系统被人们喜爱重用，有的被人们嫌弃吐槽；有的系统能够顺利改进，不断升级，有的结构混乱，频繁崩溃；有的系统架构能够自动扩容，灵活切换，有的结构死板，容易雪崩。这些情况都是有相似的规律，关键就是善于使用“测估”的方法。
即便是系统的前期做好了优秀的架构和规划，如果在运行发展的过程中，不去进行积极的“测估”，后期的系统改进升级，也一定会遇到无法预知的问题。可见，“测估”的方法是系统架构规划改进的基本方针，是系统稳健发展的成功法则。
作为系统架构的开发人员，要经常去测量评估系统节点的运行情况，在系统出现问题之前，就能做好改进优化的预备方案。想要全面准确的“测估”出系统的改进方案，通常是很难做到的，这需要经年累月的系统收集分析经验，不放过每一个系统测量数据的变化细节，通过多种手段，多种场景，进行综合的分析和规划。
本篇从四个层面，讲述了系统架构设计开发中，“测估”的使用方法，如下：
（1）“测估”既可以衡量远程服务节点的性能健康，又可以评估服务节点的稳定性和业务处理状况；
（2）测量可以从多个方面进行，包括系统的热点占比、网络环境、IO吞吐、资源占比、业务特性、核心参数、用户行为、服务交互等多个方面；
（3）评估的关键是全面掌握测量信息的发展情况，可以模拟不同的系统场景，不同的极端状况，从前端用户到核心系统的多维度多角度的深入分析；
（4）“测估”是系统改进优化的核心手段，需要经年累月的实践操作，才能逐渐掌握其中的精髓。
总之，在进行系统架构的改进优化之前，必须全面了解整个系统各个服务节点的运行情况，深入的分析评估其中的演化趋势，而最难的就是演化趋势的分析和改进方案的确定。了解的越透彻，分析的越仔细，改进优化就能够准确实施，了解的片面浅显，分析粗略，改进优化就是错误失败的。
网友评论