文章目录
- 一、微服务简介
- 1、微服务的诞生
- 2、微服务架构与SOA架构的区别
- 二、CAP理论
- 三、分布式事务
- 四、服务拆分
- 总结
一、微服务简介
1、微服务的诞生
在微服务概念出现之前还有一个概念是比较值得关注的就是SOA(面向服务架构)，它是将应用程序的不同功能单元(也可以称为是服务)进行拆分，并通过这些服务之间定义良好的接口和协议进行联系。接口是采用中立的方式进行定义，通过这种方式实现不同服务之间调用。为了实现SOA这种调用出现了ESB(企业服务总线)。而微服务也是采用了这种分治的思想，它提倡的是将单一的应用程序划分成一组最小的服务，服务之间相互协调、相互配合。
这里提到的微服务，每个服务都运行在一个独立的进程中，也就是说它是进程级别。服务之间采用的是轻量级的通信机制也就是HTTP的RESTFul API。每个服务都是基于具体的业务进行展开，并且这些业务都可以独立的部署到生产环境中。相对于ESB的系统级别的调用来说，这种服务拆分的方式更加的细粒度，但粒度越细问题就越多。
2、微服务架构与SOA架构的区别
上面提到了SOA架构，并且提到了一个ESB的概念。从上面的分析中也可以体会到，其实对于SOA来说基于ESB来实现，还是没有做到真正意义上的去中心化。也就是说如果ESB系统出现问题所有的系统调用都会出现问题。下面是来自Dubbo官网的一张图，可以看到SOA架构模式其实是基于一个ESB来进行系统级别的调用，所谓的系统级别就是A系统与B系统之间的调用是通过ESB来实现的。
微服务实现了真正意义上的分布式、去中心化。把业务系统进行了彻底的组件化和服务化，也就是前面提到的一个概念微服务中提到的服务是运行在进程中，就是说微服务中的应用是进程级别的，对于原有的业务系统进行了更细粒度的拆分。每个服务可以独立开发、独立设计、独立运行和独立运维。这些小的服务通过相互之间的调用来实现交互和集成。
对于微服务带来的问题，有很多后面有机会的话笔者会带来有关微服务所来带的有关问题，以及相关问题的解决方案。这里就先不做太多的介绍。
二、CAP理论
对于实现一个分布式的系统来说CAP原则是必须要进行了解的
- C Consistency：指数据的强一致性；也就是说数据更新完成，任意的访问节点看到的数据是完全一致的，需要和弱一致性和最终一致性进行区分
- A Availability ：指服务的可用性；所有节点都要保证高可用，这里的高可用还包括不能出现延迟，例如节点B由于等待数据同步而出现阻塞请求，那么B就不能被称为是高可用的。
- P Partition-tolerance: 指分区容错性；这里的分区其实是指网络意义上的分区，由于网络的是不可靠的，所有节点就会出现无法通讯的情况，在节点不能通信时，要保证系统可以继续的正常服务。
在网络上有很多的文章都是说CAP是分布式系统的实现原则，那就有点偏差了。CAP理论其实是对于分布式数据存储系统进行的定论。由于通常分布式系统实现的时候就必须考虑的数据持久化的问题，所以很多的人就认为两个东西是一样的。其实在很多场景中讨论CAP理论都是基于数据存储、数据复制等场景来进行讨论的。
从一个分布式应用系统来说，如果是多个分布式应用客户端所操作的数据库都是同一个数据库的话，其实对于应用本身来讲CAP是没有意义的。因为它们这些客户端所获取到的都是同样的数据，已经保证了分布式应用的数据一致性也就是实现了C原则，同时因为是多应用的，除非出现机房被炸了，一般很难出现所有的应用同时都不能用了也就是说保证了A原则。由于不涉及到应用分区，即使出现了应用分区。但是哪个只是应用级别分区，并不涉及到应用之间的数据复制操作，所以P原则看上去就没有用了。既然三个原则在应用分布式上面都没有太大的用处，那么就从侧面印证了CAP原则其实就是对于分布式的数据存储系统适用，而这个对于数据的操作附带的就是应用的分布式。所以看上去好像是整个分布式系统设计都使用的。
三、分布式事务
在上面的分析中了解了关于CAP理论。对于微服务来说其实也可以被看作是分布式的，所以不得不面对一个分布式事务的问题，对于分布式事务常用的方式就是两阶段提交和三阶段提交，不管是使用哪种方式都会出现事务的提交失败。从而导致数据不一致。下面简单的用二阶段提交来举个例子
- 第一阶段：发起一个事物，提交给事务协调器TC进行处理，TC向所有的参与事务的节点发送事务处理的消息，并且准备进行操作。所有的参与节点都进行执行准备，将Undo和Redo信息写入到日志，并向事务管理器返回准备成功。
- 第二阶段：事务管理器收集所有的节点准备操作是否成功，如果都成功，则通知所有的节点都进行提交操作，如果有一个失败了就进行事务回滚。
两阶段提交，将事务分成两部分能大大提高分布式事务成功率，如果在第一阶段都成功了，在执行第二阶段时出现节点操作失败，到时数据不准确，这个时候一般需要人工进行处理，这个是在第一步为什么要进行日志的记录。在这些操作的过程中一个最关键的东西就是IO，包括网络IO、磁盘IO等等。所以在一般情况下都是很少使用分布式事务。
四、服务拆分
对于分布式来讲其实不需要考虑对于服务的拆分，因为在分布式系统中需要考虑的是对业务系统级别的拆分。举个例子来说从上面的图中可以看到，在Dubbo给出的架构演化图中基于RPC调用的就是一个分布式的系统。与SOA系统不同就是Service被拆分了。但是会发现分布式的拆分与微服务的实现还是有一点点的差距，不能否认微服务架构是一个分布式的系统。但是分布式不一定是微服务。
微服务的拆分分为两种
- 横向拆分：按照不同的业务领域进行拆分、例如订单、营销、风控等等。都可以形成独立的微服务集群
- 纵向拆分：把一个业务功能里的不同模块或者组件进行拆分，例如把公共组件才分称为独立的自服务，下沉到底层作为底层相对独立的服务提供。
这样一纵一横的拆分就可以实现业务系统的很好的拆分。但是对于一个分布式系统来说，它可能只需要做到业务系统级别的拆分就可以了。
总之，微服务的拆分是一个渐进式的，服务内部是高内聚的，服务之间是低耦合。
微服务拆分后应该具有如下的特点
- 按照业务划分服务，单个服务代码量小，业务单一，易于维护
- 每个微服务都有独立的基础组件，例如数据库、缓存且运行在独立的进程中
- 微服务之间的通信通过HTTP 协议或者是消息组件，且具有容错能力
- 微服务有对应的服务治理方案服务之间不耦合
- 单个服务集群化部署
- 整个服务系统有安全机制
- 整个服务有链路追踪能力
- 建立完成的日志系统
总结
从上面的分析中可以感觉到，其中最为关键的就是微服务系统可以被看作是一个分布式系统，但是一个分布式系统不能被确定的叫做微服务。
