应用架构与服务治理

前段时间跟团队一起讨论城市综治网格产品的一些思路，忽然由此想到了服务治理，忽然觉得无论是城市治理还是服务治理好像都是一个思路，都是一乱一治，其中都有着一些共性的东西。还是有必要花一些时间把微服务治理的一些东西进行总结和梳理，以备咨询。

一、从单体应用到serverless，服务治理伴随应用架构逐渐成熟

随着IT技术的发展和业务需求的推动，应用的架构也经历了多个阶段，从最初的单体应用到SOA化，到分布式再到微服务，还有很多人都推崇的serverless，都在传达一个观点，那就是精细化和专业化，通俗一点说，就是拆分，把大而全的系统功能拆成小而精的小系统。按照通俗的理解，无论是人还是系统模块，数量的增加一定伴随着复杂度的上升，管理难度也会成倍和成级数增长。“大平台、微服务”已经成了这个时代的典型技术特征，各种路线和思潮，从量变积累到质变，导致我们的架构模式、开发模式、测试模式和运维模式都发生了很大变化。

1）以解决整合为目的的发展初期：其实服务治理始于SOA和服务化。随着服务化的兴起，服务治理的概念开始出现，旨在解决服务之间的整合和互联互通的问题。

2）以解决伸缩性为目的的分布式治理期：2010年之后，伴随着互联网浪潮，分布式理念对几乎所有的大中型系统进行了清洗。这一阶段，服务化的目标不仅要解决系统间的整合问题，还要解决系统的可伸缩性问题。这个时期的服务治理更多是聚焦在对服务的线上生命周期的管控及治理上，自动化成为关键手段。

3）以解决敏捷性为目的的微服务治理期：随着数字化转型的深入人心，IT从成本中心在不断向业务价值中心转型，敏捷性成为关注的焦点。换句话说，业务的发展推动我们的IT向微服务架构转型，在这个阶段服务治理已经不在局限于线上，同时也需要延伸到线下，实现线上线下一体化，才能提升整体的敏捷性。

二、可度量、可管可控是服务治理的基础和关键

1）可度量：度量是做服务治理的基础，也是最为关键的一步，“只有看得到，才能管得到”。度量实际上分成三个维度：数据采集、数据建模和数据分析。数据采集可以分成业务数据和性能数据两部分，把跟响应时间、资源消耗等等归为性能数据，把用户行为指标等主题性业务指标和应用指标归为业务数据，加上基础设施等基础性数据；数据采集之后需要对原始数据进行聚合，形成主题性数据，比如调用链等，面向服务治理，只有这些是不够的，还需要根据业务需求和治理需求，对数据进行建模，综合考虑SLO和SLI，构建服务治理模型，然后基于模型进数据分析和可视化呈现的工作。

2）可追踪：追踪是构建全链路监控和全生命周期管理的抓手。服务追踪的关键就是沿着服务调用链，对服务间的调用链路进行全景式的展示和分析。本质不仅仅是对服务路由信息的呈现，更重要的是对服务间请求以及响应状态的呈现，通过模型建设和分析对黑盒排障向白盒排障演进。

3）可管控：做到了可见和追踪，管控就有了手段和依据。管控依赖于量化采集和数据的聚合分析。服务治理对管控的要求就是从宏观向微观深入，要求能够聚焦到某个服务单元设置管控策略，比如熔断措施、限流措施等等；

三、从线上治理到线下治理，实现一体化

服务治理的具体动作根据治理对象的不同，可以分成线上和线下两部分。

1）线上治理：线上治理以服务的全生命周期管理为主，主要是服务编排和资源调度，通过整合资源编排及资源调度的能力，构建微服务的综合管控平台，可以比较方便的进行服务的上线、下线、扩容、缩容等操作。线上治理的主要动作包括服务限流、服务容错、服务降级和熔断、故障隔离、容量规划等等，每一个动作其实都有相应的工具来实现，但是千万不要认为服务治理就是工具的堆砌，就像玩摄影不是玩设备是一个道理，起关键作用的永远都是镜头后面的那个头。

2）线下治理：线下治理更多的是针对架构优化、开发过程和测试管理的管控原则和体系建设，比如架构治理中重要的是对DAG的优化和管理，以及对服务内部和服务间的内敛性和单一性的界定。还有开发治理中的代码检查和质量管理等等，以及在测试治理中如何提升测试覆盖度和降低测试单元成本。同时，也是对众多微服务团队的研发协同管理，构建高效团队。

今天听到两句话，很有意思，分享给大家。

“增加任何一行新代码，会带来N种新风险，要慎重。”

“如果有解决不了的问题，可以考虑在架构上增加一层。”