1.微服务的诞生：
- 越来越多的用户参与
- 业务场景越来越复杂
- 传统的单体架构已经很难满足互联网技术的的发展要求
- 代码的可维护性，扩展性和可读性在降低
- 维护系统的成本，修改系统的成本在提高。
微服务：是著名的OO（面向对象Object oriented）专家Martin fowler提出的。
传统的单体应用：
表示层，业务逻辑层，数据访问层都放在一个工程中，最终经过编译，打包，部署在一台服务器上。
随着业务的扩展，大多数公司会将应用进行集群部署，并增加负载均衡服务器。还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加而带来的高并发访问量。用负载均衡服务器分发高并发的网络请求，用户的访问被分派到不同的应用服务器，应用服务器的负载均衡不再成为瓶颈，用户量增加时，添加应用服务器即可。通过添加缓存服务器来缓解数据库的 数据以及数据库读取数据的压力。
- 单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差
- 面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是嫁给你数据库进行分库分表。
- 持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。
2.如何理解微服务：
- 按业务划分为一个独立运行的程序，即服务单元。
- 服务之间通过HTTP协议相互通信。
- 自动化部署
- 可以用不同的变成语言。
- 服务集中化管理
- 微服务是一个分布式系统。
按业务划分的微服务单元独立部署，运行在独立的进程中。这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何 耦合，有非常好的扩展性和复用性。
微服务通过HTTP来互相通信：
按照业务划分的微服务单元独立部署，并运行在各自的进程中。微服务单元之间的通信方式一般倾向HTTP通信。更多的时候是使用restful api。这种接受请求，处理业务逻辑，返回数据的HTTP模式非常高效，并且这种通信机制与平台和语言无关。
服务与服务之间也可以通过轻量级的消息总线来通信。例如：rabbitMq ,kafaka等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。
服务与服务通信的数据格式，一般为JSON, XML 。这两种数据格式与语言，平台，通信协议无关。一般来说，JSON格式比XML轻量，并且可读性也比XML要好。另外一种就是用protobuf进行数据序列化，经过序列化的数据为二进制数据，它比JSON更轻量。用protobuf序列化的数据为二进制，可能性非常差，必须进行反序列化才能够读懂。由于protobuf序列化的数据更轻量，所以用protobuf 在通信协议和数据存储上十分受欢迎。
服务与服务之间通过HTTP或者消息总线的方式进行通信，这种方式存在弊端，其通信机制是不可靠的，虽然成功率很高，但还是会失败的。
3.微服务的数据库独立：
在单体架构中，所有 的业务都共用一个数据库。业务量的增加，表的数量增加，数据量的增加会导致查询速度越来越慢。
微服务的一个特点就是按照业务划分服务，服务与服务之间无耦合，就是数据库也是独立的。一个典型的微服务架构就是每一个微服务都有自己独立的数据库，数据库之间没有任何联系。
好处：
- 随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用；
- 数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。
数据库的存储方式不仅仅局限于关系型数据库，非关系型数据库的应用也非常广泛，mongDB,redis它们有着良好的读写性能。
4.微服务的自动化部署：
微服务架构中，系统会被拆分成若干个微服务，每一个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。业务粒度划分的越细，微服务的数据就越多，这时就需要更稳定的部署机制。Docker，jenkins 都是比较不错的。
自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现的错误的概率降低，部署过程的每一步自动化，提高软件的质量。
5.服务集中化管理：
微服务系统是按业务单元划分服务 的，服务数量越多，管理起来越 复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如spring cloud 采用eureka 来注册服务和发现服务。另外，zookeeper，consul 等都是非常优秀的服务集中化管理框架。
6.分布式架构：
分布式系统是集群部署 的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。
微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务，全局锁，全局ID等，而单体系统不需要考虑这些复杂性。
分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络。网络不好，会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。这就是“雪崩效应”。为了防止雪崩，分布式可以采用“熔断机制”。
7.熔断机制：
为了防止雪崩效应，分布式系统采用“熔断机制”。在用spring cloud 构建的微服务系统中，采用了熔断器（hystrix组件的circuit breaker）去做熔断。
当别的服务都依赖某一个服务时，当该服务发生故障时，请求失败次数超过设定的阀值之后，该服务就会开启熔断机制，该服务不再进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。熔断器还有另外一个机制：自我修复的机制。这种自我修复机制在微服务架构中有着重要的意义，一方面，它使程序更加健壮，另一方面，为开发和运维减少很多不必要的工作。
熔断组件往往会提供一系列的监控，例如服务可用于否，熔断器是否被打开，目前的吞吐量，网络延迟状态的监控等。从而很容易的让开发人员和运维人员实时的了解服务的状态。
8.微服务的优势：
- 将一个复杂的业务分解成若干个小的业务，每一个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。服务按照业务拆分，编码也是按照业务拆分，代码的可读性和可扩展性增加。
- 由于微服务系统是分布式系统，服务与服务之间没有任何的耦合。随着业务的增加可以根据业务再拆分成服务，具有极强的横向扩展能力。随着用户量的增加，并发量增加，可以将微服务集群化部署，从而增加系统的负载能力。
- 服务与服务之间通过HTTP网络通信协议来通信，单个微服务内部高度耦合，服务与服务直接完全独立，无耦合。这使得为父可以采用任何的开发语言和技术来实现。
- 单体应用，由于业务的复杂性，代码的耦合性，以及可能存在的历史问题。再重写一个单体应用时，开发人员要熟悉所有的业务。重写的风险相当高。微服务是按照业务进行拆分的，并且有服务边界，所以重写某个服务相当于重写某个业务的代码，就非常简单。
- 微服务的每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。
- 微服务在CAP理论中采用的是AP架构，即具有高可用和分区容错的特点。高可用主要体现在系统7×24小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系统的负载能力。另外，分区容错也使得更加健壮。
9.微服务的不足：
- 微服务的复杂度
- 分布式事务
- 服务的划分
- 服务的部署
10.分布式事务：
微服务架构所涉及的系统是分布式系统。分布式系统有一个著名的CAP理论，即同时满足“一致性”，“可用性”，“分区容错”时意见不可能的事情。设计时应该有所取舍。
- Consistency:数据的强一致性。如果写入某个数据成功，之后读取，读到的都是新写入 的数据；如果写入失败，之后读取的都不是写入失败的数据。
- Availability:服务的可用性。
- Partition-tolerance:指分区容错。
在分布式系统中，P是基本要求，而单体服务是CA系统。微服务系统通常是一个AP系统，即同时满足了可用性和分区容错。
解决事务问题：
第一阶段，service-account发起一个分布式事务，交给事务协调器TC处理，事务协调器TC向所有参与事务的节点发送处理事务操作的准备的操作。所有的参与节点执行准备操作。将Undo 和Redo 信息写进日志，并向事务管理器返回准备操作是否成功。
第二阶段，事务管理器收集所有节点的准备操作是否成功，如果都成功，同通知所有的节点执行提交操作；如果有一个失败，则执行回滚操作。
两阶段提交，将事务分成两部分能够大大提高分布式事务的成功的概率。如果在第一阶段都成功了，而执行第二阶段的某一个节点失败，仍然导致数据的不准确，这时一般需要人工去处理，这就是当初在第一步记录日志的原因。