微服务
微服务
1. 前后端分离是如何做的？
前后端的分离是需要前后端共同作出一些控制的。
后端需要专注于后端控制层（最佳实践是RESTful风格的API）+服务层——数据访问层。
而前端需要专注于前端控制层（Node.js是很优秀的实例，但由于jQuery社区相当活跃，也是一种优异的选择）+视图层。
在讨论并确定API风格和开发协助模式，职责分配等项目设计阶段工作结束后，前后端需要在开发阶段各自分工，协同敏捷开发，后端提供RESTful API，并给出详细文档说明，由前端人员进行页面渲染前台的任务是发送API请求来获取数据后渲染页面。在项目部署阶段，可以利用Nginx做反向代理，即Java+node.js+Nginx方式进行。
参考：
《浅谈架构之路：前后端分离模式》
2. 微服务哪些框架
微服务是一种架构风格，一个大型复杂软件应该有一个或多个微服务组成，系统中的各个微服务可被独立部署，各个微服务之间是松耦合的，每个微服务仅关注与完成一件任务且很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务通过服务实现应用的组件化，它将组建定义为可被独立替换和升级的软甲年度按原，在应用架构设计中通过将整体应用且分为可独立部署及升级的微服务方式进行组件化设计。其次，微服务围绕业务能力组织服务，采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的，强搭配的DevOps开发运维一体化的小型团队。
微服务的这些特点让其非常适合敏捷式开发，各个部分松耦合，复杂性低，各个部分可以独立部署，能够快速迭代，当需求发生改变时，能够快速根据需求对服务进行修改使其适应新的需求。
与微服务有关的框架如下：
- Spring Boot
它的设计目的是简化新Spring应用初始搭建以及开发过程，是最受欢迎的微服务开发框架。基于其开发的便捷度简化分布式系统基础设施的开发，可以做到一键启动和一键部署。 - Spring Cloud
它是一个新兴的系列框架的合集，基于Http(s)的RESTful风格API建立服务体系，能够帮助架构师搭建一整套完整的微服务架构技术生态链。 - Dubbo
Dubbo是阿里的开源分布式服务化治理框架，通过RPC请求方式访问，在国内的流行程度甚至超过了Spring CLoud。但由于曾经一度因为项目冲突被阿里放弃而陷入几乎停止维护的困境，哪怕在Apache接手此项目后仍然受到了Spring Cloud的强大冲击，但由于其深厚历史和中文API文档，国内仍然有大批顶级企业在使用。 - Dropwizard
它将Java生态系统中各个问题域里最好的组件继承与一身，能够快速打造一个RESTful风格的后台。它相较于Spring Boot更为轻量级。 - Akka
它是一个使用Scala编写的库，可以用在有简化编写容错，高可伸缩兴的Java和Scala的Actor模型，使其可以实现微服务集群。
《做好架构师，要懂微服务，汇总微服务架构落地的15种框架》
3. Spring Could的常见组件有哪些
- Spring Cloud Config
配置管理开发工具包，允许把配置放到远程服务器，支持本地存储，Git以及SVN。 - Spring Cloud Bus
事件，消息总线，用于在集群中传播状态变化，可与Spring Cloud Config联合实现热部署。 - Spring Cloud Netflix
针对多种Netflix组件提供的开发工具包，其中包括Eureka，Hystrix，Zuul，Archaius等。 - Spring Cloud Data Flow
大数据操作工具，通过命令行方式操作数据流。 - Spring Cloud Security
安全工具包，为程序添加例如OAuth2安全控制 - Spring Cloud Zookeeper
操作Zookeeper的数据包，用于使用zookeeper方式的服务注册和发现。 - Spring Cloud Stream
数据流操作开发包，封装了与Redis，Rabbit，Kafka等发送接收消息。 - Spring Cloud CLI
基于Spring Boot CLI，可以以命令行方式快速建立云组件。
参考:
《spring.io 主要框架及spring cloud主要组件》
4. 领域驱动有了解吗？什么是领域驱动模型？充血模型、贫血模型
领域驱动模型设计(Domain Driven Design)是一套综合软件系统分析和设计的面向对象建模方法。领域模型准确反映了业务语言，而传统的J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单的setter和getter只外没有任何业务方法，被比喻为失血模型。
DDD提倡从需求开始就考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为适用服务时限，最后造成需求的首肢分离。这也被认为是SpringWeb应用的最大败笔，服务+表模型的架构使服务囊肿，难于维护拓展，伸缩性能差。DDD首先考虑的是业务语言而不是数据。
4.1 失血模型
指领域对象只有get和set方法，，所有的业务逻辑都不包含在内而是放在Service层。也就是POJO都是失血模型。
4.2 贫血模型
此模型在失血模型之上包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这些依赖于持久层的业务逻辑将会放到Service层中。它使系统层次结构清楚，各层之间单向依赖，但不是面向对象的编程思想，领域堆想只是作为保存状态或者传递状态使用，只有数据没有行为的对象不是真正的对象。
4.2 充血模型
层次结构与贫血模型基本相同，不过大多业务逻辑和持久化层的操作都放在了领域Object中。service中只是简单封装了部分业务逻辑以及控制食物，权限等。它面向对象，service符合单一职责原则，而不是像贫血模型中那样太过沉重。但它的难点是如何划分业务逻辑。
参考：
《贫血模型和充血模型》
《说说领域驱动设计和贫血、失血、充血模型》
5. JWT有了解吗，什么是JWT
Http是无状态协议，他不对之前发送过的请求和响应的状态进行管理。因此派生了Cookie和基于Cookie机制的Session来对此进行管理。但Cookie/Session这种解决方案在分布式/集群系统中会带来相当麻烦的问题：如何来实现session的同步？虽说有一些解决方案，但不是都能在最佳性能上达成100%可靠的。
因此，产生了Json Web Token。JWT是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。它是紧凑且安全的，一般用来在身份提供者和服务提供这件传递被认证的用户信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的生命信息。它可以被直接用于认证，也可以被加密。
JWT尺寸较小，因此可以通过URL，POST参数或HTTP头部发送，小体积也意味着它传输速度快。它的有效载荷包含有关用户的所有必要信息，因此变免了多次查询数据库的需求。且由于JSON的通用性，JWT是可以进行跨语言支持的。
参考：
《一步步带你了解前后端分离利器之JWT》
6. 你怎么理解 RESTful
表象性状态转移Representational Stat Transfer是web服务的一种架构风格。使用Http，url，xml，Json，Html等广泛流行的标注内核协议。它是轻量级，跨平台，跨语言的架构设计，是一种设计风格，一种思想。
REST架构将网络上所有的事务都抽象为资源，每个资源都有一个惟一的资源标识符URI，同一个资源具有类似XML，JSON等多种表现形式，对资源的各种操作都不会改变资源标识符。所有的操作都是无状态的的。
RESTful简化了之前action层中的描述性信息，例如使用GET方式访问user/query是查询，使用POST方式访问user/save是保存等操作，在REST下可以改为使用GET访问user就是查询，使用POSt访问user就是新增，使用PUT是修改而DELETE是删除。
参考：
《【Restful】三分钟彻底了解Restful最佳实践》
7. 说说如何设计一个良好的 API
此下API设计是基于RESTful风格的。
- 明确。
尽可能明确提供行为，保证方法名见名知意，最起码不能引起歧义。比如getUser()其实执行的是save()操作。 - 让api表面积尽可能小
- 减少样板。
尽可能在内部处理各种细节，以减少客户端的负担。 - 降低依赖。
保证自我封闭，依赖是一种不稳定因素和定时炸弹。 - 返回有意义的错误状态。
- 异常应该有真正的含义。
不要为一个不确定的状态导致崩溃。 - 对所有的事情要建立文档。
- 编写测试
- 变得可测试
- 允许用户选择
- 不要给用户太多选择
参考：
《如何设计一个良好的API?》
8. 如何理解 RESTful API 的幂等性
Http幂等方法被调用多少次都会有不同结果。一次和多次请求某一个资源应该具有同样的副作用。
9. 如何保证接口的幂等性
幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的. 声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试.
参考：
《接口的幂等性》
10. 说说 CAP 定理、BASE 理论
10.1 CAP定理
在一个分布式系统中，一致性Consistency，可用性Availability，分区容错性Partition tolerance三者不可兼顾。这条原则是No SQL数据库的基石。
一致性C：在分布式系统中的所有数据备份，在同一时刻是否同样的值
可用性A：在集群中一部分节点故障后，几区年整体是否还能相应客户端的读写请求
分区容忍性P：以实际效果而言，分区相当于通信的实习现要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区，就绪比在C与A之间做出抉择。
10.2 BASE理论
BASE是Basically Available基本可用，Soft State软状态和Eventually consisten最终一致性的简写。BASE是对CAP中一致性和可用性权衡的结果。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
基本可用允许分布式系统在不可预知故障的时候损失部分可用性，软状态允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。最终一致性强调系统中所有的数据副本在经过一段时间的同步后能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
参考：
《CAP原则(CAP定理)、BASE理论》
11. 怎么考虑数据一致性问题
- 规避分布式事务 -- 业务整合
不使用分布式事务。这很明显是最差的解决方案。 - eBay模式
将需要分布式处理的任务通过消息日志的方式来异步执行。 - 去哪儿网分布式事务方案
将分布式事务转换为多个本地事务，然后依靠重试等方法达到最终一致性。 - 蘑菇街分布式一致性方案
在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。 - 阿里分布式服务DTS方案
分布式事务服务是一个分布式事务框架，从架构上分为client和server两部分，前者嵌入客户端应用，负责事务数据的写入和处理，后者是一个独立的系统，主要负责异常事务的恢复。 - 农信网数据一致性方案
采用异步消息通知机制，目前主要使用 ActiveMQ，基于 Virtual Topic 的订阅方式，保证单个业务集群订阅的单次消费。
参考：
《保证分布式系统数据一致性的6种方案》
12. 说说最终一致性的实现方案
参见上题的实现方案
13. 微服务的优缺点
优点：
- 独立开发。小型独立组件可由小型独立团队构建。
- 独立部署。每个单独的组件都可以被独立部署。
- 独立的可伸缩性。每个组件可以彼此独立地进行缩放。
- 可重用性。组件实现一个小的，特定的功能，能够更容易适用于其他系统，服务或产品。
缺点：
- 开发人员的复杂性增加。开发人员想要在合作的情况下，或者可能跨越许多服务的实现一个功能的情况下，开发人员必须在他们的机器上运行它们，或者连接到它们。这通常比简单地运行单个程序更复杂。
- 运营的复杂性增加。服务太过于多，导致需要更多的沟通途径及潜在的失败领域。
- devops增加了复杂性。
- 需要严肃的专业知识。
- 现实世界的系统往往界限不清。
- 状态的复杂性往往被忽略
- 通讯等待复杂性往往被忽略
- 版本控制可能很难
- 分布式事务是一大难题
参考：
《2018年微服务将疯狂至死？带你领略不一样的思维历程！》
14. 微服务与 SOA 的区别
微服务是随着互联网的发展，复杂的平台，业务的出现而导致的SOA架构向更细粒度，更通用化程度发展而产生的。
微服务相比于SOA更加精细，以更多的独立进程的方式存在，互相之间并无影响。它提供的接口更加通用化，无关语言，平台限制。也更更加倾向于分布式去中心化的部署方式。
所以，微服务对于SOA而言，只是一种经过良好架构设计的SOA解决方案实现的面向服务的交互方案。它更专注于以自治的方式产生价值。
参考：
《SOA和微服务架构的区别？》
《SOA与微服务的区别》
《我所理解的SOA和微服务》
15. 如何拆分服务、水平分割、垂直分割
请参见数据库分库分表部分
16. 如何应对微服务的链式调用异常
- 使用分布式监控系统zipkin来具体判断是谁出了问题。
- 使用Spring Cloud组件Zuul来监控。
17. 如何快速追踪与定位问题
。。。我选择放弃
18. 如何保证微服务的安全、认证
- OAuth2
Spring Cloud可以使用OAuth2来实现多个微服务的同一认证授权。
通过向OAuth2服务进行集中认证和授权，获得access——token，然后在后续访问中携带access_token来达到微服务的统一认证授权。 - JWT
JWT是一种认证协议，具体流程与OAuth2相似，但OAuth2是一种授权框架。它适合分布式无状态的应用，轻量，简单。
参考：
《Spring Cloud中如何保证各个微服务之间调用的安全性》