本文根据DBAplus社群第89期线上分享整理而成，文末还有书送哦~ 张真 宜信技术研发中心高级架构师
主题简介：
先谈谈这个话题的早期背景，作为一个发展了十年的企业，我们公司内部存在大量的系统，这些系统可能包括多种架构，多种技术栈，它们互相关联，互相作用成就了复杂的业务体系。随着业务演变，人员更迭，系统演进等诸多因素的叠加，公司级系统的关联关系与状态逐步变得难以精确梳理，难以精细维护。 基于这样的痛点，便产生了这个话题的思考：能否使用技术手段自动地、精确地、具现化地勾勒公司级的应用/服务关联图谱？ 1服务流以及微服务架构下面临的挑战 描述关联关系会让人联想到一个词“拓扑”。拓扑是源于数学的一门方法论，它是研究与大小，形状无关的点、线关系的方法。在计算机领域，拓扑是一组计算机相关的抽象点，以及点之间联线构成的图形。 大家最熟悉的是网络拓扑，它是把计算机和通信设备抽象为一个点，把传输介质抽象为一条线，由点和线组成的几何图形，是对物理网络环境的描述。网络拓扑的核心标识是IP地址，所以每个点就是一个IP地址的抽象，而点与点之间的连线代表网线，光纤或无线连接。这个图形描绘了物理网络的静态结构。 网络拓扑举例： （注：图源自网络） 在APM（应用性能管理）领域，提供了应用拓扑。它是将终端（用户），中间件（包含应用），数据库等抽象成点，用有向的连线来描述访问关系（数据交流传输的路径）。它强调端到端的流程绘制。 应用拓扑举例： （注：图源自网络） 说说今天的话题，什么是服务流？它与前面二者的区别与联系是什么？ 服务流（ServiceExchanging Topology）是描述服务与服务的静态拓扑和运行时特性的图谱。之所以称为服务“流”，是强调它更加动态，它涵盖应用拓扑的内容，比应用拓扑提供更加深入的抽象粒度，也提供更加丰富的运行时状态。同时它不强调应用的概念，但兼容不同架构下的应用概念。 在说明服务流如何抽象节点之前，先简单梳理一下服务，应用以及进程的概念：
通常我们会面对3种架构：单体架构，SOA架构和微服务架构。 单体架构并不强调服务的概念，所以可能有服务，也可能无服务，而同一个进程中可能包含多个应用，比如Tomcat启动后，是一个进程，允许部署多个应用。如下图：
单体架构中三者的关系 从SOA开始，服务开始作为应用的必须单元，一个应用中可能包含多个服务。同时随着服务思想的发展，进程被建议部署单个应用（当然多应用也被允许），服务之间通过服务总线进行交互。如下图： SOA架构中三者的关系 微服务架构进一步强化服务的概念，要求服务成为可独立部署的单元，所以从部署形态上出现了两种基本模式：
同时微服务之间基于服务发现进行直连交互，而对外部交互通过服务网关进行。如下图： 微服务架构中三者的关系 接下来，阐述一下服务流提出的静态拓扑和运行时特性的含义。 1、静态拓扑：是描绘服务本体，服务之间的关联。 服务本体是对以下四种类型服务的抽象：
分类的标准是按照服务之间的关联特性来确定的：
2、运行时特性： 主要是描述服务过程以及调用过程的一系列监控指标。
之所以能够提供更深入的粒度是因为服务流使用了服务画像数据和客户端画像数据，第二部分会详述。所以从领域来看服务流、应用拓扑、网络拓扑又分别对应服务监控、APM、机房监控这三个领域（如下图）： 在微服务架构下，服务流的绘制存在如下挑战： 1）微服务架构在实现服务独立部署的同时，也带来服务节点规模的大幅增长，导致关联关系更加复杂。依靠人工收集变得难以落地；如果依赖Zookeeper，etcd等建立服务注册中心，虽然可以收集到服务本体的一些信息，但没有服务的关联信息，且如何更新维护依然是问题。 2）服务更加多样化，变更更频繁，且不同步。由于服务会被拆分得很细腻（有助于更加灵活的编排和独立运维），所以服务的种类自然增长，且由于可能是不同团队维护这些服务，服务的上线，变更等运维过程变得极大的不同步。 3）微服务的部署形态有多样性。例如传统JEE应用是由应用服务器提供一个端口接收访问（一进程一应用一服务）；而新的部署形态可能由服务对外提供一个或多个端口接收访问（一进程无应用一服务），如果是多个端口时，可以把这个服务看出一个聚合服务也可以将每个端口抽象成一个服务，从服务流的角度这种服务抽象需要具备聚合和分散的特性。 4）在一个复杂生产环境下，还要考虑与单体架构，SOA架构的兼容问题。例如单体架构下需要识别“服务组件”或被抽象成一个“大服务”；SOA下同一应用下可能存在多个服务，也需要被识别出来，并被分别抽象。 2自动化构建（微）服务流 对于服务流的构建，我们仍然采用了微智能的思想，希望服务流的构建过程形成完全反馈闭环。 微智能设计思想的三观 关于微智能设计思想的详述，请参考DBAplus社群的 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除 |
注册
登录
