1、您对微服务有何了解？
2、微服务架构有哪些优势？
3。微服务有哪些特点？
4、设计微服务的最佳实践是什么？
5、微服务架构如何运作？
6、微服务架构的优缺点是什么？
7、单片，SOA 和微服务架构有什么区别？
8、在使用微服务架构时，您面临哪些挑战？
9、SOA 和微服务架构之间的主要区别是什么？
10、微服务有什么特点？
11、什么是领域驱动设计？
12、为什么需要域驱动设计（DDD）？
13、什么是无所不在的语言？
14、什么是凝聚力？
15、什么是耦合？
16、什么是 REST / RESTful 以及它的用途是什么？
17、你对 Spring Boot 有什么了解？
18、什么是 Spring 引导的执行器？
19、什么是 Spring Cloud？
20、Spring Cloud 解决了哪些问题？
21、在 Spring MVC 应用程序中使用 WebMvcTest 注释有什么用处？
22。你能否给出关于休息和微服务的要点？
23、什么是不同类型的微服务测试？
24、您对 Distributed Transaction 有何了解？
25、什么是 Idempotence 以及它在哪里使用？
26、什么是有界上下文？
27、什么是双因素身份验证？
28、双因素身份验证的凭据类型有哪些？
29、什么是客户证书？
30、PACT 在微服务架构中的用途是什么？
31、什么是 OAuth？
32、康威定律是什么？
33、合同测试你懂什么？
34、什么是端到端微服务测试？
35、Container 在微服务中的用途是什么？
36、什么是微服务架构中的 DRY？
37、什么是消费者驱动的合同（CDC）？
38、Web，RESTful API 在微服务中的作用是什么？
39、您对微服务架构中的语义监控有何了解？
40、我们如何进行跨功能测试？
41、我们如何在测试中消除非决定论？
42、Mock 或 Stub 有什么区别？
43、您对 Mike Cohn 的测试金字塔了解多少？
44、Docker 的目的是什么？
45、什么是金丝雀释放？
46、什么是持续集成（CI）？
47、什么是持续监测？
48、架构师在微服务架构中的角色是什么？
49、我们可以用微服务创建状态机吗？
50、什么是微服务中的反应性扩展？

文件：590m.com/f/25127180-500868715-6e35d3（访问密码：551685）

以下内容无关：

-------------------------------------------分割线---------------------------------------------

一、现状
Vue框架在前端开发中应用广泛，当一个多人开发的Vue项目经过长期维护之后往往会沉淀出很多的公共组件，这个时候经常会出现一个人 开发了一个组件而其他维护者或新接手的人却不知道这个组件是做什么的、该怎么用，还必须得再去翻看源码，或者压根就没注意到这个组件 的存在导致重复开发。这个时候就非常需要维护对应的组件文档来保障不同开发者之间良好的协作关系了。

但是传统的手动维护文档又会带来新问题：

效率低，写文档是个费时费力的体力活，好不容易抽时间把组件开发完了回头还要写文档，想想都头大。

易出错，文档内容容易出现差错，可能与实际组件内容不一致。

不智能，组件更新迭代的同时，需要手动将变更同步到文档中，消耗时间还容易遗漏。

而理想中的文档维护方式则是：

工作量小，能够结合Vue组件自动获取相关信息，减少从头开始写文档的工作量。

信息准确，组件的关键信息与组件内容一致，不出错。

智能同步，Vue组件迭代升级时，文档内容可以自动的同步更新，无需人工校验信息是否一致。

二、社区解决方案
2.1 业务梳理
为了能实现上述理想效果，我搜索并研究了一下社区中的解决方案，目前Vue官方提供了Vue-press可以用于快速搭建Vue项目文档， 而且也已经有了可以自动从Vue组件中提取信息的库了。

但是已有的第三方库并不能完全满足需求，主要存在以下两个问题:

信息不全面，一些重要内容无法获取例如不能处理v-model，不能解析属性的修饰符sync，不能获取methods中函数入参的详细信息等。

比如下面的例子，value属性与input事件可以合起来构成一个v-model属性，但是这个信息在生成的文档中没有体现出来，要文档读者自行理解判断。而且生成的文档中没有展示是否支持sync。

有较多的自定义标识，而且标识的命名过于个性化，对原有的代码侵入还是比较大的。例如下图中的代码，为了标记注释，需要在原有的 业务代码中额外添加"@vuese" "@arg"等标识，使得业务代码多出了一些业务无关内容。

三、技术方案
针对以上文中提到的问题以及社区方案的不足，我们团队内沉淀出了一个小工具专门用于Vue组件信息获取并输出组件文档，大致效果如下：

上图中左边是一个常见的Vue单文件组件，右边是生成的文档。我们可以看到我们从组件中成功的提取到了以下一些信息：

组件的名称。

组件的说明。

props，slot，event，methods等。

组件的注释内容。

接下来我们将详细的讲解如何从组件中提取这些信息。

3.1 Vue文件解析
既然是要从Vue组件中提取信息，那么首先的问题就是如何解析Vue组件。Vue官方开发了Vue-template-compiler库专门用于Vue解析， 这里我们也可以用同样的方式来处理。通过查阅文档可知Vue-template-compiler提供了一个parseComponent方法可以对原始的Vue文件进行处理。

import { parseComponent } from ‘Vue-template-compiler’
const result = parseComponent(VueFileContent, [options])
处理后的结果如下，其中template和script分别对应Vue文件中的template和script的文本内容。

export interface SFCDescriptor {
template: SFCBlock | undefined;
script: SFCBlock | undefined;
styles: SFCBlock[];
customBlocks: SFCBlock[];
}
当然仅仅是得到文本是不够的，还需要对文本进行更进一步的处理来获取更多的信息。得到script后，我们可以用babel把js编译成js的AST（抽象语法树），这个AST是一个普通的js对象，可以通过js进行遍历和读取 有了Ast之后我们就可以从中获取到我们想到详细的组件信息了。

import { parse } from ‘@babel/parser’;
const jsAst = parse(script, [options]);
接着我们来看template，继续查找Vue-template-compiler的文档我们找到compile方法，compile是专门用于将template编译成AST的， 正好可以满足需求。

import { compile } from ‘Vue-template-compiler’
const templateAst = compile(template, [options]);
得到结果中的ast则为template的编译结果。

export interface CompiledResult {
ast: ASTElement,
render: string,
staticRenderFns: Array,
errors: Array
}
通过第一步的文件解析工作，我们成功获取到了Vue的模板ast和script中的js的AST，下一步我们就可以从中获取我们想要的信息了。

3.2 信息提取
根据是否需要约定，信息可以分为两种：

一种是可以直接从Vue组件中获取，例如props、events等。

另一种是需要额外约定格式的，例如：组件的说明注释，props的属性说明等，这部分可以放到注释里，通过对注释进行解析获取。

为了方便的从ast中读取信息，这里先简单介绍一个工具@babel/traverse，这个库是babel官方提供的专门用于遍历js AST的。使用方式如下；

import traverse from ‘@babel/traverse’

traverse(jsAst, options);
通过在options中配置对应内容的回调函数，可以获得想要的ast节点。具体的使用可以参考官方文档

3.2.1 可直接获取的信息
可以从代码中直接获取的信息可以有效的解决信息同步问题，无论代码怎么变动，文档的关键信息都可以自动同步，省去了人工校对的麻烦。

可以直接获取的信息有：

组件属性props

提供外部调用的方法methods

事件events

插槽slots

1、2都可以利用traverse在js AST上直接遍历名称为props和methods的对象节点获取。

事件的获取稍微麻烦一点，可以通过查找 e m i t 函 数 来 定 位 到 事 件 的 位 置 ， 而 emit函数来定位到事件的位置，而 emit函数来定位到事件的位置，而emit函数可以在traverse中监听MemberExpress(复杂类型节点)， 然后通过节点上的属性名是否是’ e m i t ′ 判 断 是 否 是 事 件 。 如 果 是 事 件 ， 那 么 在 emit'判断是否是事件。如果是事件，那么在 emit′判断是否是事件。如果是事件，那么在emit父级中读取arguments字段， arguments的第一个元素就是事件名称，后面的元素为事件传参。

this.KaTeX parse error: Expected '}', got 'EOF' at end of input: …erty.name === 'emit’) {
// 第一个元素是事件名称
const eventName = Node.parent.arguments[0];
}
}
});
在成功获取到Events后，那么结合Events和props，就可以进一步的判断出props中的两个特殊属性：

是否存在v-model：查找props中是否存在value属性并且Events中是否存在input事件来确定。

props的某个属性是否支持sync：判断Events的时间名中是否存在有update开头的事件，并且事件名称与属性名相同。

插槽slots的信息保存在上文的template的AST中，递归遍历template AST找到名为slots的节点，进而还可以在节点上查找到name。

3.2.2 需要约定的信息
为什么除了可直接获取的组件信息之外,还会需要额外的约定一部分内容呢？其一是因为可直接获取的信息内容比较单薄，还不足以支撑起一个相对完善的组件文档；其二是我们日常开发组件时本身就会写很多的注释，如果能直接将部分注释提取出来放到文档中，可以大大降低文档维护的工作量；

整理一下可以约定的内容有以下几条：

组件名称。

组件的整体介绍。

props、Events、methods、slots文字说明。

Methods标记和入参的详细说明。这些内容都可以放在注释中进行维护，之所以放在注释中进行维护是因为注释可以很容易从上文提到的js AST以及template AST中获取到， 在我们解析Vue组件信息的同时就可以把这部分针对性的说明一起解析到。

接下来我们着重讲解如何将提取注释和注释与被注释的内容是如何对应起来的。

js中的注释根据位置不同可以分为头部注释(leadingComments)和尾部注释(trailingComments)，不同位置的注释会存放在对应的字段中， 代码展示如下:

// 头部注释export default {} // 尾部注释
解析结果

const exportNode = {
type: “ExportDefaultDeclaration”,
leadingComments: [{
type: ‘CommentLine’,
value: ‘头部注释’
}],
trailingComments: [{
type: ‘CommentLine’,
value: ‘尾部注释’
}]
}
在同一个位置上，根据注释格式的不同又分为单行注释(CommentLine)和块级注释(CommentBlock)，两种注释的区别会反应在注释节点的type字段中：

/**

• 块级注释
  */
  // 单行注释
  export default {}
  解析结果

const exportNode = {
type: “ExportDefaultDeclaration”,
leadingComments: [
{
type: ‘CommentBlock’,
value: ‘块级注释’
},
{
type: ‘CommentLine’,
value: ‘单行注释’
}
]
}
另外，从上面的解析结果我们也可以看到，注释节点是挂载在被注释的export节点里面的，这也解决我们上面提到的另一个问题：注释与被注释的关联关系怎么获取的–其实babel在编译代码的时候已经替我们做好了。

template查找注释与被注释内容的方法不同。template中注释节点与其他节点一样是作为dom节点存在的， 在遍历节点的时候通过判断isComment字段的值是否为true来确定是否是注释节点。而被注释的内容的位置在兄弟节点的后一位：

被注释的节点
解析结果

const templateAst = [
{
isComment: true,
text: “template的注释”,
type: 3
},
{
tag: “slot”,
type: 1
}
]
知道了如何处理注释内容，那么我们还可以利用注释做更多的事情。例如可以通过在methods的方法的注释中约定一个标记@public来区分是私有方法还是公共方法，如果更细节一点的话， 还可以参考另一个专门用于解析js注释的库js-doc的格式，对方法的入参进行更进一步的说明，丰富文档的内容。

我们只需要在获取到注释内容之后对文本进行切割读取即可，例如：

export default {
methods: {
/**
* @public
* @param {boolean} value 入参说明
*/
show(value) {}
}
}
当然了为了避免对代码侵入过多，我们还是需要尽量少的添加额外的标识。而入参说明采用了与js-doc相同的格式，主要还是因为这套方案 使用比较普遍，而且代码编辑器都自动支持方便编辑。