微服务简介

单体架构的不足

       在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下3个方面。
        业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。                                                        随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
        测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度
的增加，单体应用修改业务或者增加业务或许会给其他业务带来一定的影响，导致测
试难度增加。

单体架构使用集群服务器及存在的不足

       系统仍然为单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差。
       面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表。
       持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。新人熟悉代码的时间长、成本高。                                                                                                                                由此看见，在应用初期，单体应用从成本、开发时间和运维等方面都有明显的优势。但是随着业务量和用户量的增加，它所暴露出来的缺点也显而易见。单体架构已经不能满足复杂的业务和海量的用户系统，改变单体架构势在必行。  

微服务

微服务通过HTTP来进行通信

按照业务划分的微服务单元独立部署，并运行在各自的进程中。微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制，更多的时候是使用RESTfulAPI的。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效，并且这这种通信机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务，用Go写的服务又可以消费用Ruby写的服务。不同的服务采用不同的语言去实现，不同的平台去部署，它们之间使用HTTP进行通信。

微服务的数据库独立 

微服务连数据库是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供 API接口相互调用;还有一个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。

服务集中化管理 

微服务系统是按业务单元来划分服务的，服务数量越多 管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如 Spring Cloud 采用Eureka来注册服务和发现服务，另外，Zookeeper、Consul等都是非常优秀的服务集中化管理框架。

微服务的优势

 (1)将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。服务按照业务拆分，编码也是按照业务来拆分，代码的可读性和可扩展性增加。新人加入团队，不需要了解所有的业务代码，只需要了解他所接管的服务的代码，新人学习时间成本减少。
 (2)由于微服务系统是分布式系统，服务与服务之间湾没有任何的耦合。随着业务的增加，可以根据业务再拆分服务，具有极强的横向扩展能力。随着应用的用户量的增加，并发量增加，可以将微服务集群化部署，从而增加系统的负载能力。简而言之，微服务系统的微服务单元具有很强的横向扩展能力。                                                                                                                                     (3)服务与服务之间通过HTTP网络通信协议来通信，单个微服务内部高度耦合，服务与
服务之间完全独立，无耦合。这使得微服务可以采用任何的开发语言和技术来实现。开发人员
不再被强迫使用公司以前的技术或者已经过时的技术,而是可以自由选择最适合业务场景的或者最适合自己的开发语言和技术，提高开发效率、降低开发成本。
 (4)如果是一个单体的应用，由于业务的复杂性、代码的耦合性，以及可能存在的历史问
题。在重写一个单体应用时，要求重写的应用的人员了解所有的业务，所以重写单体应用是非常困难的，并且重写风险也较高。如果是微服务系统，由于微服务系统是按照业务的进行拆分的，并且有坚实的服务边界，所以重写某个服务就相当于重写某一个业务的代码，非常简单。
 (5)微服务的每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。试想，假设一个应用只有一个简单的修改，如果是单体架构，需要测试和部署整个应用;而如果采用微服务架构，只需要测试并部署被修改的那个服务，这就大大减少了测试和部署的时间。
 (6)微服务在CAP理论中采用的是AP架构，即具有高可用和分区容错的特点。高可用主要体现在系统7x24小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系统的负载能力。另外，分区容错也使得系统更加健壮。

微服务的不足

       构建一个微服务系统并不是一件容易的事，微服务系统是分布式系统，构建的复杂度远远超过单体系统，开发人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。
      另外服务与服务之间相互依赖，如果修改某一个服务， 会对另外一个服务产生影响，如果 
掌控不好，会产生不必要的麻烦。由于服务的依赖性，测试也会变得复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试。

分布式事务

       微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP 理论，即同时满足“一致性”“可用性”和“分区容错”是一件不可能的事。CAP理论是由 Eric Brewer在2000年PODC会议上提出的，该理论在两年后被证明成立。CAP理论告诉架构师不要妄想设计出同时满足三者的系统，应该有所取舍，设计出适合业务的系统。
Consistency:指数据的强一致性。如果写入某个数据成功，之后读取，读到的都是新写入的数据;如果写入失败，之后读取的都不是写入失败的数据。                                                              Availability:指服务的可用性。                                                                                                    Partition-tolerance:指分区容错。

如果这是一个单体应用，并且使用支持事务的MySQL 数据库(InnoDB 数据库引擎才支持事务)，我们可能这样写代码:

 如果是微服务架构，账户是一个服务，而商品是一个服务，这时不能用数据库自带的事务，
因为这两个数据表不在一个数据库中。因此常常用到两阶段提交。

 两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都成功了，而执行第二阶段的某一个节点失败，仍然导致数据的不准确，这时一般需要人工去处理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某一个节点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。所以一般情况下，尽量少用分布式事务。