分布式微服务架构设计原理
分布式微服务架构设计原理
背景：
1、传统的软件技术更倾向服务于企业，用户较少，所以传统的企业级技术无法满足互联网产品服务于海量用户的需求。
2、之前的部署方式:部署在同一个应用服务器上，跑在一个JVM进程中。
ORM-对象关系映射
att: 高度抽象的ORM框架被证明有性能上的瓶颈，后来大家都更加倾向于使用更加灵活的MyBatis来实现ORM层。
ESB-企业服务总线
EJB-企业级JavaBean(Enterprise JavaBean)，EJB是一个用来构筑企业级应用的服务器端可被管理组件。Java企业版API（Java Enterprise Edition）中提供了对EJB的规范。
Component-组件是对数据和方法的简单封装。
SSH-truts、spring和hibernate
SOA-面向服务的架构
SOA在这一时代的数据通信格式通常是xml，因为xml标记定义在大规模，高并发通信过程中，冗余的标记会给性能带来极大的影响，后来被Json取代。
webService-是SOA服务化的一种是实现方式
它使得运行在不同的机器及操作系统上的互相发现和调用成为可能，并且可以通过某种协议来交换数据。http，rpc等等(提供接口供外部访问)。通过WSDL定义的服务发现接口进行访问，并通过SOAP协议进行通信。
restful风格的API通常是在http和https通道上传输json格式的数据来实现的，http协议具有跨语言、跨异构系统的特点，当然也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。
1、微服务架构与SOA服务化的对比
微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华并落地的一种实现方式。
(1)目的不同
SOA服务设计的范围更广一些，强调不同额度异构服务之间的写作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为webService和ESB。
微服务使用一系列的微小服务来实现整体的业务流程，目的是有效的拆分应用，实现敏捷开发和部署，在每个微小服务的团队中，减少跨团队的交流，让专业的人做专业的事情，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的。
(2)部署方式不同
微服务将完整的应用拆分成多个细小的服务，每个服务运行在单一的进程中，为服务之间的部署互相独立，互不影响。
SOA服务通常将多个业务服务通过组件化模块方式打包在一个war包中，然后统一部署在一个应用服务器上。
(3)服务粒度
微服务提倡将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理。
SOA对粒度没有要求。
2、微服务的交互模式
(1)读者容错模式
在服务接口的定义中，参数可以使用枚举值，在返回值的DTO中进制使用枚举值(反序列化会报错)。
(2)消费者驱动契约模式
定义服务化中服务之间交互接口改变的最佳规则。
服务提供者契约：服务提供者单方面定下的规则。
服务消费者契约：消费者将自己的约定给服务者，服务者契约中包含这部分规定即可，会成为服务提供者契约的一部分。
消费者驱动契约：多个消费者对服务者提出约束，服务提供者遵守。
(3)去数据共享模式
微服务是去中心化及分布式的，微服务之间的交互通过良好的接口来实现，不允许通过使用共享数据来实现。
在设计微服务架构时，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式和API或者透明的RPC调用框架。
在java领域，每个服务上线之后，对外输出的接口为一个jar包。在微服务领域，jar包被分为一方库，二方库和三方库。
一方库：本服务在JVM进程内依赖的jar包
二方库：在服务外通过网络通信或者是RPC调用的服务jar包
三方库：所依赖的其他公司或者组织提供的服务或者模块。
att:微服务并不是为了拆分而拆分，真正的目的是通过对为服务进行水平扩展解决传统的单体应用在业务急剧增长是遇到的问题。
3、SOA时代的服务化框架和平台
Dubbo<阿里开源，开发的比较早，后期没有维护，对微服务的熔断、限流、服务隔离等设计的不好>
HSF
Thrift
4、微服务
springBoot：将容器嵌入到自启动的jar包中，在springboot容器启动的时候内部自动嵌入容器
Netflix：由Netflix公司开发合并到SpingCloud项目中，主要提供服务发现、断路器等等功能。
springCloudNetflix:集成了springBoot和Netflix功能；
单体架构:将所有功能都部署在一个web容器中运行的系统就叫做单体架构(巨石型应用)
SOA: Service-Oriented Architecture 面向服务的架构。SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去，可以理解为一批服务的组合。SOA将原来的单体架构按照功能细分为不同的子系统，然后再由各个子系统依赖服务中间件来调用所需服务。使用SOA将系统切分为多个组件服务，这种通过多个组件服务来完成请求的方式有很多好处，比如不同团队的可以负责不同的子项目；模块拆分，使用通讯接口，降低了模块之间的耦合度等等。
微服务: 一种架构风格和架构思想，它倡导文明在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API(一般使用REST API)，可以独立承担对外服务的职责。
单体架构:所有的服务都杂糅打包在一起。
ATT:
SOA:按功能分成多个服务，典型代表是webService<有一个webService的目录>。
微服务:服务的粒度更细，需要去中心化<去掉webService目录>。
二、解决分布式系统一致性的问题
一致性:指分布式服务系统之间的弱一致性，包括应用系统的一致性和数据的一致性。
分而治之的思想和逻辑
水平拆分:单一节点无法满足性能需求，所以扩展成多个节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分的请求量，所有节点共同处理大规模高并发的请求量。
垂直拆分:按照功能进行拆分，把复杂的功能拆分成为更加单一简单的功能，不同的功能组合到一起，和未拆分前的功能是一样的。
ACID:原子性、一致性、隔离性、持久性
CAP:一致性、可用性、分区容忍性
BASE:基本可用、软状态(状态可以在一段时间内不同步)、最终一致(在一定的时间窗口内，最终数据达成一致)
TCC:try、confirm、cancel
三、大数据日志系统的搭建
业务系统应用日志:一般使用Commons logging、Log4j、Slf4j、Logback、Log4j2等，业务日志一般分为trace、debug、warn、info和error等，线上系统根据其特性设置的也不同。
JDK自带的Logging日志框架比较鸡肋，在易用性，功能及扩展性方面都逊色，在线上很少被使用。
Apache Commons Logging:
Apache Log4j:
Slf4j用来取代Apache Commons Logging
Logback用来取代Log4j
Apache Log4j2:Log4j的升级版本
开发人员的日志意识
1、开发代码时要有意识设想代码出现问题时的场景，针对出问题的场景记录关键的程序运行时的信息，这样在代码出现问题时才能通过日志恢复程序运行的过程，才容易定位问题。
2、打印日志时必须包含环境信息，环境信息是指在打印日志时可获得的帮助开发人员定位问题的信息。例如：id，角色，参数，返回值，逻辑判断结果，循环次数，异常信息等。
3、对异常等错误信息必须打印错误级别及以上的日志，对线上日志要定期检查，没有异常日志产生的服务才是正常的服务。
4、生成环境将关闭的日志必须在打印日志前判断，以此来提高执行效率。
5、必须使用占位符的方式进行字符串连接，这样程序更加简洁，并且性能有所提高。
6、对关键业务步骤必须打点并记录耗时等结果信息。
Att:
(1)上线后稳定的系统，使用info级别的日志
(2)常年不出现问题的系统使用error几倍的日志即可
(3)toString()方法的实现需要考虑连接字符串是否可能产生NullPointerException