1.2微服务--微服务简介
微服务简介
一、微服务的定义
微服务：用来描述将软件应用程序设计为独立部署的服务的一种特殊方式，其系统是一个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、 容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。
单体架构存在的不足：
1）业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降
2）随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限
3）测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张，单体应用修改业务会给其他业务带来一定的影响，导致测试难度增加
单体架构使用服务器集群及存在的不足：
【单体服务的集群化】
1）系统仍然为单体应用 ，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差
2）面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表
3）持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长
微服务架构的风格就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信【通常是 HTTP RESTFUL API】
这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。 这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理
二、微服务的特点
微服务具有如下特点：
1）按业务划分为一个独立运行的程序，即服务单元
2）服务之间通过 HTTP 协议相互通信
3）自动化部署
4）可以用不同的编程语言
5）可以用不同的存储技术
6）服务集中化管理
7）微服务是一个分布式系统
详解---1. 微服务通过 HTTP 来互相通信
服务与服务通信的数据格式， 一般为 JSON、 XML, 这两种数据格式与语言、平台、通信协议无关，JSON 格式的数据比 XML 轻量，井且可读性也比 XML 好
另外一种就是用 Protobuf进行数据序列化，不同语言、平台的微服务经过序列化的数据为二进制数据，它比 JSON 更轻量。 相互调用Protobuf序列化的数据为二进制数据，可读性非常差， 需要反序列化才能够读懂。由于用 Protobuf序列化的数据更为轻量，所以 Protobuf在通信协议和数据存储上十分受欢迎
详解---2. 微服务的数据库独立
微服务的一个特点就是按业务划分服务，服务与服务之间无耦合，就连数据库也是独立的
一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。
这样做的好处在于：1）随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供 API 接口相互调用
2）数据库独立，单业务的数据盆少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便
详解---3. 微服务的自动化部署
在微服务架构中，系统会被拆分为若干个微服务， 每个微服务又是一个独立的应用程序。
单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次
随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加
业务的粒度划分得越细，微服务的数量就越多，这时需要更稳定的部署机制
随着Docker 容器技术的推进，以及自动化部署工具（例如开源组件 Jenkins）的出现，自动化部署变得越来越简单
详解---4.分布式架构
分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求;
分布式系统的复杂任务通过计算机之间的相互协作来完成
分布式系统通过网络协议来通信
微服务架构是分布式架构， 分布式系统比单体系统更加复杂，主要体现在服务的独立性和服 务相互调用的可靠性，以及分布式事务、全局锁、 全局 Id 等， 而单体系统不需要考虑这些复杂性
详解---5. 熔断机制
为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制
在用 Spring Cloud 构建的微服务系统中，采用了熔断器（即 Hystrix 组件的 Circuit Breaker）去做熔断处理
当服务 b 出现故障，请求失败次数超过设定的阀值之后，服务 b 就会开启熔断器，之后服务 b 不进行任何的业务逻辑操作，执行快速 失败，直接返回请求失败的信息
其他依赖于 b 的服务就不会因为得不到响应而线程阻塞，这 时除了服务 b 和依赖于服务 b 的部分功能不可用外，其他功能正常
熔断服务 b 如图所示：
熔断器还有另外一个机制——自我修复的机制：
当服务b 熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其他请求执行快边失败，检查的请求如果响应成功，则可以判定服务b 正常了，就会关闭服务b 的熔断器；如果服务b 还不正常，则继续打开熔断器。它使程序更加健壮
三、微服务的优势
1、将复杂的问题简单化
将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务和编码均按照业务拆分，使开发者无需了解所有的业务代码，只需要专注于自己负责的代码即可
2 、横向扩展能力优秀
由于微服务系统的服务与服务之间没有任何的耦合。随着业务和用户量的增加，可以将微服务集群化部署，从而增加系统的负载能力
3、提高开发效率、降低开发成本
服务与服务之问通过HTTP 网络通信协议来通信，单个微服务内部高度耦合，服务与服务之间完全独立。
微服务可以采用任何的开发语言和技术来实现，开发人员可以自由选择最适合业务场景的或者最适合自己的开发语言和技术
4、重写服务简单
在重写一个单体应用时，要求重写的应用的人员了解所有的业务，难度大
由于微服务系统是按照业务进行拆分的，所以重写某个服务就相当于重写某一个业务的代码，比较简单
5 、减少了测试和部署的时间
微服务的每个服务单元都是独立部署的，其修改和部署对其他服务没有影响
修改只需要测试并部署被修改的那个服务，可以极大减少测试和部署的时间
6、提高系统负载能力
微服务在CAP 理论中采用的是AP 架构，即具有高可用和分区容错的特点。
高可用主要体现在系统7 x 24 小时不间断的服务，要求系统有大量的服务器集群，从而提高了系统的负载能力
另外，分区容错也使得系统更加健壮
四、微服务的不足
1）微服务的复杂度
微服务系统是分布式系统，构建的复杂度远远超过单体系统，开发人员需要掌握更多的架构知识和框架知识
服务与服务之间通过HTTP 协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险
由于服务的依赖性，测试也会变得复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试
2）分布式事务
微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP 理论，即同时满足“ 一致性”“可用性”和“分区容错”是一件不可能的事；
CAP 理论如图：
Consistency：指数据的强一致性。如果写入某个数据成功，之后读取，读到的都是新写入的数据；如果写入失败，之后读取的都不是写入失败的数据
Availability ：指服务的可用性
Partition-tolerance：指分区容错
微服务架构，账户是一个服务，而商品是一个服务，这时不能用数据库自带的事务，因为这两个数据表不在一个数据库中
这时需要用到两阶段提交：
第一阶段：service-account 发起一个分布式事务，交给事务协调器处理，事务协调器向所有参与的事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作，将Undo 和Redo 信息写进日志，并向事务管理器返回准备操作是否成功
第二阶段，事务管理器收集所有节点的准备操作是否成功，如果都成功，则通知所有的节点执行提交操作；如果有一个失败，则执行回滚操作
两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都成功了，而执行第二阶段的某一个节点失败，仍然导致数据的不准确，这时一般需要人工去处理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某一个节点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。所以尽量少用分布式事务
3）服务的划分
将一个完整的系统拆分成很多个服务，是一件非常困难的事，因为这涉及了具体的业务场景，服务是可以被替换和更新的。也就是服务和服务之间无耦合，任何一个服务都可以被替换，服务有自己严格的边界。
根据具体的业务场景来拆分服务， 需要依靠团队人员对业务的熟悉程度和理解，程度，并考虑与己有架构的冲突、业务的扩展性、开发的风险和未来业务的发展等诸多因素。
领域驱动设计是一个全新的概念，也是一个比较理想的微服务拆分的理念。领域驱动设计通过代码和数据分析找到合理的切分点，并通过数据分析来判断服务的划分边界和划分粒度。
4）服务的部署
一个简单的单体系统可能只需要将程序集群部署井配置负载均衡服务器即可，而部署一个复杂的微服务架构的系统就复杂得多。
部署微服务系统，需要开发人员或者运维人员对微服务系统有足够强的控制力。随着云计算和云服务器的发展，部署微服务系统并不是一件难事，这就是人们往往提到微服务，就会想到Docker 、DevOps 的原因。
其中，微服务是核心： Docker 为容器技术，是微服务最佳部署的容器： DevOps 是一种部署手段或理念。
在微服务架构中，有三大难题，那就是服务故障的传播性、服务的划分和分布式事务。
为了解决服务故障的传播性， 一般的微服务框架都有熔断机制组件。
服务的划分没有具体的划分方法， 一般来说根据业务来划分服务， 领域驱动设计具有指导作用。
分布式事务一般的解决办法就是两阶段提交或者三阶段提交，不管使用哪一种都存在事务失败，导致数据不一致的情况，关键时刻还得人工去恢复数据
总之，微服务的设计一定是渐进式的，并且是随着业务的发展而发展的
————————————————————————————————————————————