前后端开发概述（四）

​ 把一些前后端概念性比较强的理念放在这里，本片涉及web components等

堡垒机/跳板机

https://github.com/jumpserver/jumpserver

计算机审计系统

计算机审计是以被审计单位计算机信息系统和底层数据库原始数据为切入点，在对信息系统进行检查测评的基础上，通过对底层数据的采集清理、汇聚整合，形成审计中间表，构建模型进行分析，发现联系、趋势、异常和错误，把握总体、突出重点、精确延伸，从而收集审计证据，实现审计目标的审计方式。（刘汝焯《计算机审计：概念、框架与规则》）

计算机审计包括两个方面的内容：一是对计算机信息系统进行检查，包括设计、运行及输入输出的数据等方面；二是利用计算机技术手段进行审计。

信息系统审计可以界定为：根据公认的标准与指导规范，对信息系统从计划、研发、实施到运行维护各个环节进行审查评价，对信息系统及其业务应用的完整、效能、效率、安全性进行检测、评估和控制的过程，以确认预定的业务目标得以实现，并提出一系列改进建议的管理活动。（黄作明《信息系统审计》）

IT审计即信息技术审计，在企业现有的信息系统基础上，利用一系列信息技术手段对系统内的业务应用进行审查。

总的来说，以上四个概念皆是信息技术革命背景下的产物，依赖于计算机技术而发展。至于他们之间的区别，小编的理解是：审计信息化相对来说比较宏观，是为了顺应现代化审计的需要而催生的一个新概念，最终目的是为了促进审计工作的长远发展，计算机只是实现审计信息化的一种手段、一种必要设施。而计算机审计、信息系统审计、IT审计这三个概念则属于审计的不同类别，计算机审计包含信息系统审计与IT 审计。从广义上来说，信息系统审计与IT审计都是针对信息系统的审计，而且都利用了信息技术。但信息系统审计更侧重于对信息系统本身的审查，即判断这个系统是否有效做到无漏洞、保护资产、维护数据完整和完成组织目标；而IT审计更加强调在审计过程中对先进信息技术手段的有效利用和对信息技术的审计。

日志审计系统

综合日志审计平台，通过集中采集信息系统中的系统安全事件、用户访问记录、系统运行日志、系统运行状态等各类信息，经过规范化、过滤、归并和告警分析等处理后，以统一格式的日志形式进行集中存储和管理，结合丰富的日志统计汇总及关联分析功能，实现对信息系统日志的全面审计。

通过日志审计系统，企业管理员随时了解整个IT系统的运行情况，及时发现系统异常事件；另一方面，通过事后分析和丰富的报表系统，管理员可以方便高效地对信息系统进行有针对性的安全审计。遇到特殊安全事件和系统故障，日志审计系统可以帮助管理员进行故障快速定位，并提供客观依据进行追查和恢复

为什么需要日志审计平台

日志审计的合规要求，由于网络安全法的颁布实施，由原先的不合规转变成了不合法。如果不对要求的相关日志不做留存6个月以上，一旦追查，将面临法律责任。 安全运营的挑战。随着网络设备的增多，以及服务器数量的增多，如果没有统一的综合日志审计平台，那么需要登录到每台设备上查看日志，不利于运维人员管理。而且众多设备会产生海量的日志，无法有效管理。多种设备形成信息孤岛，日志无法关联分析。通过统一的日志审计平台，将所有设备日志都收集到日志平台进行统一管理，统一分析。

日志审计的核心目标

• 多源数据归一化
• 日志存储集中化
• 关联分析自动化
• 安全态势立体化

日志审计的主要功能

统一日志采集：

对不同日志源 (主机系统、网络设备、安全设备、应用中间件、数据库等)所产生的日志进行收集，实现日志的集中管理和存储。支持解析任意格式、任意来源的日志，通过解析规则标准化。 使用无代理的方式收集日志。

支持代理方式的日志收集。 关联分析： 预置多种事件关联规则。 定位外部威胁、黑客攻击、内部违规操作，设备异常。 简单灵活定义关联规则。 实时告警： 通过邮件、短信、声音对发生的告警进行及时通知，并可通过接口调用自动运行程序或脚本。 通过告警策略定义，对各类风险 和事件进行及时告警或预警，提升运维效率。 日志取证分析： 深入分析原始日志事件，快速定位问题的根本原因。 生成取证报表，例如攻击威胁报表、Windows/Linux系统审计报表以及合规性审计报表等。 监管合规： 提供Windows审计、Linux审计、PCI、SOX、ISO27001等合规性报表。

支持创建自定义合规性报表

日志转发方式

日志转发一般可以通过：Syslog转发，Kafka转发，http转发。

日志收集一般支持：Syslog、SNMP等日志协议。

日志审计系统模块

日志事件获取模块：安全事件监控系统是实时掌握全网的安全威胁状况的重要手段之一。通过事件监控模块监控各个网络设备、主机系统等日志信息，以及安全产品的安全事件报警信息等，及时发现正在和已经发生的安全事件，通过响应模块采取措施，保证网络和业务系统的安全、可靠运行。

资产管理模块：资产管理实现对网络安全管理平台所管辖的设备和系统对象的管理。它将其所辖IP设备资产信息按其重要程度分类登记入库，并为其他安全管理模块提供信息接口。

规则库模块：规则库已支持主流网络设备、主机系统、数据库系统等，而且还应涵盖已经部署的安全系统，包括防火墙系统、防病毒系统等。并提供新日志格式适配功能，支持从安全运营中心平台接收新日志解析映射规则配置。用户可以根据该适配功能，对新日志格式进行自行适配。

统计报表功能：具备强大的统计功能，可快速生成多种专业化的报表并支持自定义图表的设定集展示。

权限管理模块：超级管理员可根据用户角色分配平台查看、操作各模块的权限，用户可以访问而且只能访问自己被授权的资源

微服务

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等

尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目，优点是：

• 开发简单直接，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销

当然它的缺点也十分明显，特别对于互联网公司来说：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

优点

微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。

其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。

第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。

最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。

缺点：

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单，因为单体应用往往只存在一个数据库。但在微服务架构下，不同服务可能拥有不同的数据库。CAP原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。

Web Components

组件是前端的发展方向，现在流行的 React 和 Vue 都是组件框架。

谷歌公司由于掌握了 Chrome 浏览器，一直在推动浏览器的原生组件，即 Web Components API。相比第三方框架，原生组件简单直接，符合直觉，不用加载任何外部模块，代码量小。目前，它还在不断发展，但已经可用于生产环境。

template标签

使用 JavaScript 写上一节的 DOM 结构很麻烦，Web Components API 提供了<template>标签，可以在它里面使用 HTML 定义 DOM。

<template id="userCardTemplate">
  <img src="https://semantic-ui.com/images/avatar2/large/kristy.png" class="image">
  <div class="container">
    <p class="name">User Name</p>
    <p class="email">yourmail@some-email.com</p>
    <button class="button">Follow</button>
  </div>
</template>

然后，改写一下自定义元素的类，为自定义元素加载<template>。

class UserCard extends HTMLElement {
  constructor() {
    super();

    var templateElem = document.getElementById('userCardTemplate');
    var content = templateElem.content.cloneNode(true);
    this.appendChild(content);
  }
}  

添加样式

自定义元素还没有样式，可以给它指定全局样式，或者局部样式

user-card {
  /* ... */
}

<template id="userCardTemplate">
  <style>
   :host {
     display: flex;
     align-items: center;
     width: 450px;
     height: 180px;
     background-color: #d4d4d4;
     border: 1px solid #d5d5d5;
     box-shadow: 1px 1px 5px rgba(0, 0, 0, 0.1);
     border-radius: 3px;
     overflow: hidden;
     padding: 10px;
     box-sizing: border-box;
     font-family: 'Poppins', sans-serif;
   }
   .image {
     flex: 0 0 auto;
     width: 160px;
     height: 160px;
     vertical-align: middle;
     border-radius: 5px;
   }
   .container {
     box-sizing: border-box;
     padding: 20px;
     height: 160px;
   }
   .container > .name {
     font-size: 20px;
     font-weight: 600;
     line-height: 1;
     margin: 0;
     margin-bottom: 5px;
   }
   .container > .email {
     font-size: 12px;
     opacity: 0.75;
     line-height: 1;
     margin: 0;
     margin-bottom: 15px;
   }
   .container > .button {
     padding: 10px 25px;
     font-size: 12px;
     border-radius: 5px;
     text-transform: uppercase;
   }
  </style>

  <img src="https://semantic-ui.com/images/avatar2/large/kristy.png" class="image">
  <div class="container">
    <p class="name">User Name</p>
    <p class="email">yourmail@some-email.com</p>
    <button class="button">Follow</button>
  </div>
</template>

shadow DOM

我们不希望用户能够看到<user-card>的内部代码，Web Component 允许内部代码隐藏起来，这叫做 Shadow DOM，即这部分 DOM 默认与外部 DOM 隔离，内部任何代码都无法影响外部。

自定义元素的this.attachShadow()方法开启 Shadow DOM

class UserCard extends HTMLElement {
  constructor() {
    super();
    
    var shadow = this.attachShadow( { mode: 'closed' } );

    var templateElem = document.getElementById('userCardTemplate');
    var content = templateElem.content.cloneNode(true);
    content.querySelector('img').setAttribute('src', this.getAttribute('image'));
    content.querySelector('.container>.name').innerText = this.getAttribute('name');
    content.querySelector('.container>.email').innerText = this.getAttribute('email');

    shadow.appendChild(content);
  }
}
window.customElements.define('user-card', UserCard);

上面代码中，this.attachShadow()方法的参数{ mode: 'closed' }，表示 Shadow DOM 是封闭的，不允许外部访问。

2021年js开发调查

https://2021.stateofjs.com/zh-Hans/features

clean code

clean code，顾名思义就是整洁的代码，或者说清晰、漂亮的代码

代码大部分时候是用来维护的，而不是用来实现功能的

这个原则适用于大部分的工程。我们的代码，一方面是编译好让机器执行，完成功能需求；另一方面，是写给身边的队友和自己看的，需要长期维护，而且大部分项目都不是朝生夕死的短命鬼。

大部分情况下，如果不能写出清晰好看的代码，可能自己一时爽快，后续维护付出的代价和成本将远高于你的想象。

对清晰好看代码的追求精神，比所有的技巧都要重要

优秀的代码大部分是可以自描述的，好于文档和注释

当你翻看很多开源代码时，会发现注释甚至比我们自己写的项目都少，但是却能看的很舒服。当读完源码时，很多功能设计就都清晰明了了。通过仔细斟酌的方法命名、清晰的流程控制，代码本身就可以拿出来当作文档使用，而且它永远不会过期。

相反，注释不能让写的烂的代码变的更好。如果别人只能依靠注释读懂你的代码的时候，你一定要反思代码出现了什么问题（当然，这里不是说大家不要写注释了）。

说下比较适合写注释的两种场景： 1. public interface，向别人明确发布你功能的语义，输入输出，且不需要关注实现。 2. 功能容易有歧义的点，或者涉及比较深层专业知识的时候。比如，如果你写一个客户端，各种config参数的含义等。

设计模式只是手段，代码清晰才是目的

之前见过一些所谓“高手”的代码都比较抽象，各种工厂、各种继承。想找到一个实现总是要山路十八弯，一个工程里大部分的类是抽象类或者接口，找不到一两句实现的代码，整个读起代码来很不顺畅。我跟他聊起来的时候，他的主要立场是：保留合适的扩展点，克服掉所有的硬编码。

其实在我看来，也许他的代码被“过度设计”了。首先必须要承认的是，在同一个公司工作的同事，水平是参差不齐的。无论你用了如何高大上的设计，如果大多数人都不能理解你的代码或者读起来很费劲的话，其实这是一个失败的设计。

当你的系统内大部分抽象只有一个实现的时候，要好好思考一下，是不是设计有点过度了，清晰永远是第一准则。

保持clean code的手段

code review

很多大公司会用git的pull request机制来做code review。我们重点应该review什么？是代码的格式、业务逻辑还是代码风格？我想说的是，凡是能通过机器检查出来的事情，无需通过人。比如换行、注释、方法长度、代码重复等。除了基本功能需求的逻辑合理没有bug外，我们更应该关注代码的设计与风格。比如，一段功能是不是应该属于一个类、是不是有很多相似的功能可以抽取出来复用、代码太过冗长难懂等等。

我个人非常推崇集体code review，因为很多时候，组里相对高级的工程师能够一眼发现代码存在较大设计缺陷，提出改进意见或者重构方式。我们可以在整个小组内形成一个好的文化传承和风格统一，并且很大程度上培养了大家对clean code的热情。

勤于重构

好的代码，一般都不是一撮而就的。即使一开始设计的代码非常优秀，随着业务的快速迭代，也可能被改的面目全非。

为了避免重构带来的负面影响（delay需求或者带来bug），我们需要做好以下的功课： ① 掌握一些常见的“无痛”重构技巧，这在下文会有具体讲解。 ② 小步快跑，不要企图一口吃成个胖子。改一点，测试一点，一方面减少代码merge的痛苦，另一方面减少上线的风险。 ③ 建立自动化测试机制，要做到即使代码改坏了，也能保证系统最小核心功能的可用，并且保证自己修改的部分被测试覆盖到。 ④ 熟练掌握IDE的自动重构功能。这些会很大程度上减少我们的体力劳动，避免犯错。

静态检查

现在市面上有很多代码静态检查的工具，也是发现bug和风格不好的比较容易的方式。可以与发布系统做集成，强制把主要问题修复掉才可以上线。目前美团技术团队内部的研发流程中已经普遍接入了Sonar质量管理平台。

多读开源代码和身边优秀同学的代码啊

感谢开源社区，为我们提供了这么好的学习机会。无论是JDK的源码，还是经典的Netty、Spring、Jetty，还是一些小工具如Guava等，都是clean code的典范。多多学习，多多反思和总结，必有收益。

通用技巧

单一职责

这是整洁代码的最重要也是最基本的原则了。简单来讲，大到一个module、一个package，小到一个class、一个method乃至一个属性，都应该承载一个明确的职责。要定义的东西，如果不能用一句话描述清楚职责，就把它拆掉。

我们平时写代码时，最容易犯的错误是：一个方法干了好几件事或者一个类承载了许多功能。

优先定义整体框架

写代码的时候，比较喜欢先去定义整体的框架，就是写很多空实现，来把整体的业务流程穿起来。良好的方法签名，用入参和出参来控制流程。这样能够避免陷入业务细节无法自拔。在脑海中先定义清楚流程的几个阶段，并为每个阶段找到合适的方法／类归属。

这样做的好处是，阅读你代码的人，无论读到什么深度，都可以清晰地了解每一层的职能，如果不care下一层的实现，完全可以跳过不看，并且方法的粒度也会恰到好处。

比较推崇写代码的时候“广度优先”而不是“深度优先”，这和我读代码的方式是一致的。当然，这件事情跟个人的思维习惯有一定的关系，可能对抽象思维能力要求会更高一些。如果开始写代码的时候这些不够清晰，起码要通过不断地重构，使代码达到这样的成色

清晰的命名

老生常谈的话题，这里不展开讲了，但是必须要mark一下。有的时候，我思考一个方法命名的时间，比写一段代码的时间还长。原因还是那个逻辑：每当你写出一个类似于”temp”、”a”、”b”这样变量的时候，后面每一个维护代码的人，都需要用几倍的精力才能理顺。

并且这也是代码自描述最重要的基础。

避免过多的参数

如果一个方法的参数长度超过4个，就需要警惕了。一方面，没有人能够记得清楚这些函数的语义；另一方面，代码的可读性会很差；最后，如果参数非常多，意味着一定有很多参数，在很多场景下，是没有用的，我们只能构造默认值的方式来传递。

解决这个问题的方法很简单，一般情况下我们会构造paramObject。用一个struct或者一个class来承载数据，一般这种对象是value object，不可变对象。这样，能极大程度提高代码的可复用性和可读性。在必要的时候，提供合适的build方法，来简化上层代码的开发成本。

避免过长的方法和类

一个类或者方法过长的时候，读者总是很崩溃的。简单地把方法、类和职责拆细，往往会有立竿见影的成效。以类为例，拆分的维度有很多，常见的是横向／纵向。例如，如果一个service，处理的是跟一个库表对象相关的所有逻辑，横向拆分就是根据业务，把建立／更新／修改／通知等逻辑拆到不同的类里去；而纵向拆分，指的是 把数据库操作/MQ操作/Cache操作/对象校验等，拆到不同的对象里去，让主流程尽量简单可控，让同一个类，表达尽量同一个维度的东西。

相同长度的代码表示相同粒度的逻辑

https://tech.meituan.com/2017/01/19/clean-code.html

重构原则

https://refactoring.com/

1.拆分巨型类/巨型组件/巨型函数