微服务常见问题FAQ
根据 Gartner 的说法，微服务是云开发的新应用平台。微服务是独立部署和管理的，一旦应用实现在容器内，它们与底层操作系统的交互很少。因此，如果你希望把微服务添加到自己的技术栈中，并想要了解与之相关的技能，那么现在正是潜心研究的时候。
在本文中，我收集了面试官最常问到的问题。
说说微服务架构的优势
- 独立开发 ：所有微服务都可以根据各自的功能轻松开发
- 独立部署 ：根据他们所提供的服务，可以在任何应用中单独部署
- 故障隔离 ：即使应用中的一个服务不起作用，系统仍然继续运行
- 混合技术栈：可以用不同的语言和技术来构建同一应用程序的不同服务
- 粒度缩放 ：各个组件可根据需要进行扩展，无需将所有组件融合到一起
你对微服务是怎么理解的？
- 微服务，又名微服务架构，是一种架构风格，它将应用构建为一个小型自治服务的集合，以业务领域为模型。
- 通俗地说，就像蜜蜂通过对蜡制的等边六角形单元来构建它们的蜂巢。
- 他们最初从使用各种材料的小单元开始，一点点的搭建出一个大型蜂巢。
- 这些小单元组成坚固的结构，将蜂窝的特定部分固定在一起。
- 这里，每个小单元都独立于另一个，但它也与其他小单元相关。
- 这意味着对一个小单元的损害不会损害其他的单元，因此，蜜蜂可以在不影响完整蜂巢的情况下重建这些单元。
请参考上图。这里，每个六边形都代表单独的服务组件。与蜜蜂的工作类似，每个敏捷团队都使用可用的框架和所选的技术栈构建单独的服务组件。就像在蜂巢中一样，这些服务组件形成一个强大的微服务架构，以提供更好的可扩展性。此外敏捷团队可以单独处理每个服务组件的问题，而不会对整个应用程序产生影响或使影响最小。
微服务有哪些特点？
- 解耦（Decoupling） - 系统内的服务很大程度上是分离的。因此整个应用可以被轻松构建、修改和扩展
- 组件化（Componentization） - 微服务被视为可以被轻松替换和升级的独立组件
- 业务能力（Business Capabilities） - 微服务非常简单，专注于单一功能
- 自治（Autonomy） - 开发人员和团队可以相互独立工作，从而提高效率
- 持续交付（ContinousDelivery） - 允许频繁发版，通过系统自动化完成对软件的创建、测试和审核，
- 责任（Responsibility） - 微服务不把程序作为项目去关注。相反，他们将程序视为自己负责的产品
- 分散治理（Decentralized Governance） - 重点是用正确的工具去做正确的事。这意味着没有任何标准化模式或技术模式。开发人员可以自由选择最合适的工具来解决自己的问题
- 敏捷性（Agility） - 微服务支持敏捷开发。任何新功能都可以快速开发并被再次丢弃
设计微服务的最佳实践是什么？
- 为每个微服务分开数据存储
- 将代码保持在类似的成熟度等级上
- 为每个微服务进行单独的构建
- 部署到容器中
- 将服务器视为无状态的
微服务架构的优点和缺点是什么？
微服务架构的优点 ， 微服务架构的缺点，可以自由使用不同的技术，增加故障排除的难度|，每个微服务都专注于单一功能|由于远程调用而导致延迟增加，支持单个可部署单元，增加配置和其他操作的工作量，允许软件的持续发布，难以维持处理的安全性，可确保每项服务的安全性，很难跟踪各种边界的数据，并行开发和部署多个服务，服务之间难以编码
单体应用 SOA 和微服务架构有什么区别？
- 单体应用类似于一个大容器，其中程序的所有组件都被组装在一起并紧密包装。
- SOA是一组相互通信的服务。通信可以涉及简单的数据传送，也可以涉及两个或多个协调某些活动的服务。
- 微服务架构是一种架构风格，它将应用程序构建为以业务域为模型的小型自治服务集合。
在使用微服务架构，你面临的挑战是什么
开发较小的微服务听起来很容易，但在开发时会经常遇到一些挑战。
- 自动化组件：难以自动化，因为有许多较小的组件。对于每个组件，都必须采取构建、发布和监控的步骤。
- 可感知性：将大量组件维持在一起会带来难以部署、维护、监控和识别的问题。它需要在所有组件周围具有很好的感知能力。
- 配置管理：有时在各种环境中维护组件的配置会很困难。
- 调试：很难找到与产生的错误相关的每一项服务。维护一个集中式的日志和控制面板对调试问题至关重要。
什么是通用语言（UL）？
如果你必须定义通用语言（UL），那么它是特定域的开发人员和用户使用的通用语言，通过该语言可以轻松解释领域。
通用语言必须非常清晰，以便将所有团队成员处于同一水平线上，并以机器可以理解的方式进行翻译。
什么是内聚？
内聚是一个模块内部各元素之间相关联程度的度量
什么是耦合？
组件之间依赖关系强度的度量被称为耦合。好的设计总是高内聚和低耦合的。
什么是REST/RESTful ？它的用途是？
Representational State Transfer（REST）/ RESTful （表述性状态转移）是一种帮助计算机系统通过 Internet 进行通信的架构风格。这使得微服务更容易理解和实现。
微服务可以用 RESTful API 来实现，当然也可以不用，但是用 RESTful API 去构建松散耦合的微服务总是更容易些。
微服务之间是如何通讯的？
第一种：远程过程调用（Remote Procedure Invocation）
直接通过远程过程调用来访问别的service。
示例：REST、gRPC、Apache、Thrift
优点：简单，常见。因为没有中间件代理，系统更简单
缺点：只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应
降低了可用性，因为客户端和服务端在请求过程中必须都是可用的
第二种：消息
使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。
示例：Apache Kafka、RabbitMQ
优点:
- 把客户端和服务端解耦，更松耦合 提高可用性，因为消息中间件缓存了消息，直到消费者可以消费
- 支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应
缺点：消息中间件有额外的复杂性
摘自： http://mp.weixin.qq.com/s?__biz=MzIzODIzNzE0NQ==&mid=2654425819&idx=1&sn=6bcbf385a0d5f3b36dc31c8846c78e1c
