微服务面试相关内容了解下~（二）

原文地址：微服务面试相关内容了解下~（二）

1、使用微服务架构有哪些挑战？

1. 自动化组件：难以自动化，因为有许多较小的组件，因此对每个组件都必须遵循Build、Deploy、Monitor的各个阶段。

2. 易感性：将大量组件维护在一起变得难以部署、维护、监控、识别问题，需在所有组件周围具有很好的感知能力。

3. 配置管理：在各种环境中维护组件的配置变得困难。

4. 调试：很难找到错误的每一项服务，维护集中式日志记录和仪表盘用以调试问题至关重要。

2、SOA和微服务架构间的主要区别？

SOA：

1. 遵循【尽可能多的共享】架构方法。

2. 重要性在于【业务功能】重用。

3. 有共同的治理和标准。

4. 使用企业服务总线（ESB）进行通信。

5. 支持多种消息协议。

6. 多线程，有更多的开销来处理I/O。

7. 最大化应用程序服务的可重用性。

8. 常用传统的关系型数据库。

9. 系统的变化需修改整体。

10. DevOps/Continuous Delivery正在变得流行，但还不是主流。

微服务架构：

1. 遵循【尽可能少分享】架构方法。

2. 重要性在于【有界背景】概念。

3. 专注于人们的合作和其它选择的自由。

4. 简单的消息系统。

5. 使用轻量级协议，如HTTP/REST等。

6. 单线程，通常使用Event Loop功能进行非锁定I/O处理。

7. 专注于解耦。

8. 常用现代关系型数据库。

9. 系统的变化是创造一种新的服务。

10. 专注于DevOps/持续交付。

3、微服务的特点？

总结如下：

1. 围绕业务功能进行组织（organized around business capability），不再是纵向分割，调整为按业务功能横向划分，一个微服务最好由一个小团队针对一个业务单元来构建。

2. 做产品而非做项目（product not project），不再是做完一个个项目，交付后就完工了，而是做产品，从设计编码到产品运维，做到全过程掌握和负责，也就是自己构建，自己维护（you build it，you run it）。

3. 智能终端加简单通道（smart endpoints and dumb pipe），使用基于资源的API，将大量逻辑放在客户端，而服务端侧重于提供资源，推荐基于Web，而不是在Web之后做复杂逻辑（be of the Web，not behind the Web）。

4. 去中心化管理（decentralized governance），自我管理，自己干自己的，不必局限在一个系统里，不必围绕着一个中心。

5. 去中心化数据管理（decentralized data management），只管理和维护自己的数据，相互之间不直接访问彼此的数据，只通过API来存取数据。

6. 基础设施自动化（infrastructure automation），每个微服务应该关注于自己的业务功能的实现，基础设施应尽量自动化，也就是构建自动化、测试自动化、部署自动化、监控自动化。

7. 为应对失败而设计（design for failure），设计之初就要考虑高可靠性（high reliability）和灾难恢复（disaster recover），并考虑如何着手进行错误监测和错误诊断。

8. 演进设计（evolutionary design），没有完美的架构，唯一不变的是变化，要善于应对变化，容易改变其设计和实现，因其小，固其易变。

4、领域驱动设计（Domain Driven Design）？

对应解释如下：

1. 关注核心域逻辑（focuse on core domain logic）。

2. 在领域模型上找到复杂的设计（find complex design on models of the domain）。

3. 不断与领域专家合作，以改进应用程序模型并解决与领域相关的问题（constantly collaborate with domain experts to improve application model and toresolve domain related issues）。

个人理解DDD三要素如下：

1. 专业知识：前期与客户沟通问题过程中，学习到关于业务方面的知识，这类知识并不仅是对需求的理解，还需思考业务需求实际要解决的是什么问题。

2. 抽象能力：发现核心业务对象，简化问题空间的能力，将复杂的需求抽象出需要解决的实际问题，如系统录单，可理解为信息入库，而不需在一开始就考虑是用手机录入还是用电脑录入。

3. 细分问题：将业务问题细化为更小更容易解决的子问题，从业务角度来看，一个业务领域可划分为多个子领域，对应的业务问题也可划分为更多小问题。

抽象和划分领域决定了系统设计的下限，专业知识决定系统设计的上限。

5、为什么需要领域驱动设计（DDD）？

翻译如下：

1. 映射到域（mapping to domain）。

2. 降低复杂性（reduced complexity）。

3. 可测试性（testability）。

4. 可维护性（maintainability）。

5. 知识丰富的设计（knowledge rich design）。

6. 将业务和服务结合在一起（brings business and service together）。

7. 以上下文为中心（context focused）。

8. 统一语言和语境（ubiquitous language）。

6、什么是无所不在的语言？

如必须定义统一业务语言和语境（ubiquitous language），那么UL是特定域的开发人员和用户使用的通用语言，通过该语言可轻松解释域，无所不在的语言必须十分清晰，以便其将所有团队成员放在同一平面上，并以机器可以理解的方式进行翻译。

7、什么是凝聚力？

模块内部元素所属程度被认为是凝聚力。

8、什么是耦合？

组件之间依赖关系强度的度量被认为是耦合，一个好的设计总是被认为具有高内聚力和低耦合性。

9、REST/RESTful及用途？

Representational State Transfer（REST）/RESTful Web服务是一种帮助计算机通过Internet进行通信的架构风格，使得微服务更易理解和实现。

微服务可使用也可不使用RESTful API实现，但使用RESTful API构建松散耦合的微服务是比较容易的。

10、不同类型的微服务测试？

使用微服务时，由于有多个微服务协同工作，测试工作就变得非常复杂，也正是如此，测试工作可分为不同的级别，如下：

1. 底层有面向技术的测试，如单元测试和性能测试，完全是自动化的。

2. 中间层可进行如压力测试和可用性测试之类的探索性测试。

3. 顶层验收测试数量很少，这些测试有助于利益相关者理解和验证软件功能。

至此，本次分享就结束了，后期会慢慢补充。

以上仅为个人观点，不一定准确，能帮到各位那是最好的。

好啦，到这里本文就结束了，喜欢的话就来个三连击吧。

扫码关注公众号，获取更多优质内容。