IT主要分为哪几类？每一类主要是做的什么？每一类主要是从事什么工作？需要详细点

计算机网络体系结构的认识

1、 计算机网络是一个涉及计算机技术、通讯技术等多个方面的复杂系统。现在计算机网络在工业、商业、军事、政府、教育、家庭、等领域。网络中的各部分都必须遵照合理而严谨的结构话管理规则。这也是计算机网络体系结构研究的内容

体系结构是研究系统各部分组成及相互关系的技术科学。所谓网络体系就是为了完成计算机之间的通信合作，把每台计算几乎连的功能划分成有明确定义的层次，并固定了同层次的进程通信的协议及相邻之间的接口及服务，将纸屑层次进程通讯的协议及相邻层的接口统称为网络体系结构。

2、 网络体系结构中涉及到了：协议、实体、接口

计算机网络中实现通信就必须依靠网络通过协议。在20世纪70年代，各大计算机生产商的产品都拥有自己的网络通信协议。但是不同的厂家生产的计算机系统就难以连接，为了实现不同厂商生产的计算机系统之间以及不同网络之间的数据通信，国际标准话组织ISO（开放系统互连参考模型）即OSI/RM也称为ISO/OSI，该系统称为开放系统。

物理层是OSI/RM的最低层，物理层包括：1通信接口与传输媒体的物理特性 2物理层的数据交换单元为二进制比特 3比特的同步 4线路的连接 5物理拓扑结构 6传输方法

数据链路层是OSI/RM的第2层它包括：成帧、物理地址寻址、流量控制、差错控制、接口控制

网络层是计算机通信子网的最高层，有：逻辑地址寻址、路由功能、流量控制、拥塞控制

其它层次：传输层、会话层、表示层和应用层

计算机也拥有TCP/IP的体系结构即传输控制协议/网际协议。TCP/IP包括TCP/IP的层次结构和协议集

OSIT与TCP/IP有着许多的共同点和不同点

在企业级应用架构的语境下，流水号具有穿针引线的作用。这里说的企业级有两层含义，一是多应用，多数企业都有一组职能定位各不相同的应用系统提供IT支撑；二是这些应用系统是一个有机整体，而不是相互隔离的。服务的调用和数据的简单传递并不是企业级的充分表达，通过多个职责不同的应用系统配合、协作而完成一系列相关服务场景，这些应用系统才能成为企业级。

银行应用系统是企业级的一种典型应用，其每一个服务场景都需要通过交易渠道、客户信息管理系统、渠道整合、流程审批、业务处理、记账处理、核算处理、客户通知……等一系列应用系统协同，当用户在页面上的一个 *** 作涉及到后台的一系列系统服务集成的时候，就需要一种流水号的设计体系对这些服务进行串接，记录在整个交易场景下各个应用的服务调用状态，以便于时候的查询、统计、分析、补录、基于原服务的二次交易等后续场景的使用。

我们简单梳理流水号的应用场景，以作为流水号设计方案的靶向标的：

SOA架构体系是应用系统专业化、复杂化发展的必然结果。 早期银行只有一个综合业务系统，所有的业务都在一个系统里实现，随着业务发展越来越复杂、越来越精细化各类专业业务系统由此诞生，原来一站式服务调用不适用了，要完成一个应用场景需要穿透三四个、乃至七八个应用系统。对于每一个后端应用系统来说，都只提供单一的、独立的、原子的服务，而对于渠道和客户来说提供的是一个场景，这时候就需要使用流水号将对服务的调用和场景关联起来。这有点类似于浏览器的无状态请求通过sessionid进行关联类似，当然不完全相同。

我们看一个典型的SOA服务调用场景。

渠道应用是面向客户服务的，所以其服务的颗粒度是场景级的，比如说：渠道对客户提供的是一个开户服务（图中的系统A），而不会关注客户在哪里建立、卡在哪里建立、账户在哪里建立等。而原子服务层应用便是后台的专业应用系统，就是我们上文说的客户、卡、账户管理的系统（图中的系统C、D），但是这些系统随着专业化、服务化、原子化，其上业务场景的属性逐渐削弱（理想状态下是没有场景）；这时候，当当当当……服务整合层强势登场，它提供了一个从原子化的服务到面向客户场景的桥梁，对同类场景进行整合发布，即是面向个性化业务需求的专项业务系统。在联创智融，我们叫他业务整合平台，它提供了可视化的开发平台、完善的高并发、高可用与异常处理机制、成熟的监控运营平台，通过提供完整的服务整合框架让应用开发从技术细节中脱离出来，专注于应用场景的开发，充分利用现有应用系统服务能力实现差异化的业务需求……（不好意思，没忍住，插播一段广告）

之所以要铺垫这么多，是因为流水号的设计基本思路是对SOA架构体系的落地。分析上图流程，客户直接使用的是渠道类系统A，我们假设S001，代表此次请求；应用系统之间还有多次服务调用，假如A->B是A001，B->C是B001，B->D是B002。很明显，客户的一次服务请求是通过后台的三次服务交互完成的，客户的请求S001和后台的请求A001、B001、B002性质完全不同。客户的请求是基于应用场景的，是一个开户请求、转账请求；后台的服务调用是基于应用服务的，是一个客户核验、记账请求、人行转出请求。为了让整个应用链路都保持S001的服务请求状态，需要将S001向下游每一次服务调用传递，并和A001、B001、B002建立映射关系。

我们将对客户展现的、面向交易场景的流水号S001，叫做 全局流水号 ；将面向服务请求、代表一次服务调用的流水号A001叫做 请求流水号 。全局流水号有在一个请求链条中保持不变的含义。其中请注意全局流水号和交易场景以及客户服务的区别，详见下图。一次客户服务指的是客户一次业务办理的整个生命周期，可以称为一个会话或者一个session，在这个会话周期内，客户可以办理多个业务（活转定、理财、取现……）而不用重复验证身份，新一代银行可以做到一次支付、一次验密、一次打印等。一个交易场景就是客户具体办理一个业务（存款），其中又可能涉及对后台的多次服务请求，比如客户身份核验就是在正式办理业务之前的一个预处理的步骤，但是也需要柜面和后台交互，这样在一个交易场景内，至少有两次到后台的用户请求。

客户会话级和交易场景级的流水号本次话题并不涉及，因为这两个状态主要在渠道类应用保持和使用，对于整体的应用架构体系并没有要求。

场景化的内容是否适合放到后端业务系统？

作为引申话题我们稍微展开一下：“场景化的业务内容是否适合放到后端业务系统？”。所谓场景化的业务指的是面向客户服务，而不是面向业务处理的业务逻辑，比如说客户校验、代理人信息、授权流程等。在很多银行的业务系统中，这些内容都在核心，这是历史遗留包袱，从上面的简单分析来看，这些内容都应该在场景层（也就是业务整合层）去实现。如果放到后端系统，会有几个问题：1、面向场景的业务处理要重复实现，没有必要且浪费效率；2、在专业化趋势下后端业务系统（主要是金融产品系统）并不需要此类业务信息，和本身的业务处理逻辑无关；3、从技术角度，场景化的内容如果放在后端，与之对应的将是全局流水号，但是后台系统的服务调用都是基于请求流水号，这个矛盾对于该笔流水的后续使用会产生很多不利影响，比如修改、数据整合等等。

本章从服务调用类型分析流水号的使用和关注的问题。根据个人经验对服务调用类型总结如下：

正向调用没什么特别需要说明的，就是一个正常的服务场景的调用。但是会涉及服务调用失败的情况下的重试情况，这时候要求下游系统能够辨别出重试交易，所以对于重试类服务，要求上游系统不能生成新的请求流水号，继续使用原请求流水号，如果下游系统上次服务调用时没有成功，则重新完成本次服务；如果已经成功完成，但是由于返回超时等原因，则不重复执行，直接返回交易已成功。

一些基本的规范说明：

这里的反向调用指的是原服务已经成功处理（也可能没有成功处理）的情况下，根据业务规定或者用户发起对原始服务进行逆 *** 作，一般叫这类服务为冲正，对应的账务处理是抹账。在SOA架构体系下，需要遵循原路来、原路冲的处理原则，否则会因为找不到原始服务调用请求而冲正失败。

从数据完整性上也应该将交易链路中所有节点都做冲正 *** 作，还原业务状态、回写账户、恢复额度等处理。所以从原则上，支持客户冲正的场景，在所有服务请求链路上，都应该提供相应服务的冲正服务，以便基于场景冲正时进行调用。

冲正是一个业务概念，可以是客户发起的，也可能是系统在交易失败后自动发起的。对于客户发起的冲正，其面向的是一个完整的交易请求，也就是全局流水号；对于系统间自动冲正，其面向的是一次服务调用，所以使用请求流水号。也就是说，需要在人机交互切面上（渠道），进行全局流水号和请求流水号的转换，客户在主动发起冲正时，输入的是全局流水号，而渠道需要根据此全局流水号，找到原始的请求流水号，并使用此请求流水号向下游系统发起冲正。下游系统再转换为本系统的请求流水号发起后续冲正服务调用，以此完成整个交易链路的反向冲正。

系统间冲正应使用请求流水号的第二个原因是，部分业务场景可能涉及到对统一系统的多次服务调用，而冲正时可能只冲正部分服务。这时候如果使用全局流水号就无法将前后多次调用的请求区分开，比如某些银行在跨分支行记账时，对记账失败的流水只冲正当前节点，而不是对整个交易请求进行冲正。

也有一些银行系统为了简化系统调用关系，只冲账务性流水，而对中间的业务状态（比如中间业务的状态、支付的状态等）并不关注，为了简单起见，直接到核心冲正站账务流水，这种方式也叫抹账。根据我们上面的分析，这时候如果使用请求流水号则找不到当前业务的交易流水，需要使用全局流水号进行冲正。

总结：原则上，对于冲正业务，客户输入的应该是全局流水号，而系统服务调用应使用请求流水号；但是不能一概而论，需要根据业务场景分析是对整个业务场景的冲正还是一次服务调用的冲正。

基于单笔业务流水的后续 *** 作，比如对原业务流水的查询、补录、修改等业务动作，严格来说冲正也属于这类 *** 作；将冲正与此类业务分开主要是因为此类业务可能与原服务调用链路不一致。参考下图，有可能原始业务出于组装服务场景的需要，经过了B系统，而后续业务因为指向性、针对性较明确，不需要复杂的处理逻辑，这时候可以直接调用C系统的其它服务。

对于此类业务，除需要传递本业务的全局流水号、请求流水号以外，还需要将原业务的流水号作为服务调用参数传递。

这类服务应使用全局流水号还是请求流水号？

这又是一个没有标准答案的问题。如果后续业务的服务调用路径和原业务调用路径一致，比如说原业务是A->B->C->D，后续业务也是A->B->C->D，那么此时可以使用“原业务请求流水号”作为服务参数；如果调用路径不一致，比如说后续业务是后续业务也是A->B->D，那么使用“原业务请求流水号”作为调用参数则找不到原业务流水，更无从谈起后续业务。参考上图，其实是一个错误的示例，你发现了吗？