《深刻理解Spring Cloud与微服务构建》第1章 微服务简介

一、单体架构及其存在的不足

1.一、单体架构简介

一个典型的单体应用就是将全部的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终通过编译打包，部署在一台服务器上。

1.二、单体架构存在的不足

• 业务愈来愈复杂，单体应用的代码量愈来愈大，代码的可读性、可维护性和可扩展性降低，新人接手代码所需的时间成倍增长，业务扩展带来的代价愈来愈大。
• 随着用户的愈来愈多，程序承受的并发愈来愈高，单体应用的并发能力有限。
• 测试的难度愈来愈大。

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

用负载均衡服务器分发高并发的网络请求，用户访问被分派到不一样的应用服务器，应用服务器的负载再也不成为瓶颈，用户量增长时，添加应用服务器便可。经过添加缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操做是由缓存完成的，可是仍然由少数读操做是从数据库读取的，例如缓存失效、实时数据等。当有大量的读写操做时，将数据库进行读写分离是一个不错的选择，例如MySQL的主从热备份，经过相关配置能够将主数据库服务器的数据同步到从数据库服务器，实现数据库的读写分离，读写分离可以改善数据库的负载能力。

这种架构有必定的处理高并发的能力，也能应对必定复杂的业务需求，改善了系统的性能，可是依然没有改变系统为单体架构的事实，此时存在的不足之处以下。

• 系统仍然为单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然不好。
• 面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表。
• 持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。新人熟悉代码的时间越长，成本高。

因此，单体架构已经不能知足复杂的业务和海量的用户系统，改变单体架构势在必行。

二、微服务

简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每一个微服务运行在本身的进程中，并使用轻量级机制通讯，一般是 HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并经过彻底自动化部署机制来独立部署。这些服务可使用不一样的编程语言，以及不一样数据存储技术，以保证最低限度的集中式管理。

2.一、微服务单元按业务来划分

按业务划分的微服务单元独立部署，运行在独立的进程中。这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的耦合，有很是好的扩展性和复用性。

2.二、微服务经过HTTP来互相通讯

微服务单元之间的通讯方式通常倾向于使用HTTP这种简单的通讯机制，更多的时候是使用RESTful API的。这种接受请求、处理业务逻辑、返回数据的HTTP模式很是高效，而且这种通讯机制与平台和语言无关。

服务与服务之间也能够经过轻量级的消息总线来通讯，例如RabbitMQ、Kafaka等。经过发送消息或者订阅消息来达到服务与服务之间通讯的目的。

它们通讯的数据格式通常为JSON、XML，与语言、平台、通讯协议无关。JSON格式的数据比XML轻量，而且可读性也比XML好。

2.三、微服务的数据库独立

一个典型的微服务架构就是每一个微服务都有本身独立的数据库，数据库之间没有任何联系。这样作的好处在于，随着业务的不断扩张，服务与服务不须要提供数据库集成，而是提供API接口相互调用；还有一个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优点，数据库的迁移也很方便。每一个服务的数据库不必定都相同，它们所使用的数据存储技术须要根据业务需求来选择。

2.四、微服务的自动化部署

自动化部署能够提升部署的效率，减小人为的控制，部署过程当中出现错误的几率下降，部署过程的每一步自动化，提升软件的质量。

2.五、服务集中化管理

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

2.六、分布式架构

微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体如今服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局ID等，而单体系统不须要考虑这些复杂性。

另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通讯依赖于网络，网络很差，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，若是一个服务出现了故障或者是网络延迟，在高并发的状况下，会致使线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。因为服务的相互依赖，可能会致使整个系统的不可用，这就是“雪崩效应”。

2.七、熔断机制

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。当某服务出现故障，请求失败次数超过设定的阀值以后，该服务就会开启熔断器，以后该服务不进行任何的业务逻辑操做，执行快速失败，直接返回请求失败的信息。

三、微服务的优点和不足

3.一、微服务的优点

• 复杂的业务分解成若干小的业务，服务按业务划分，边界明确，将复杂的问题简单化。
• 微服务系统的微服务单元具备很强的横向扩展能力。
• 服务与服务之间经过HTTP网络通讯协议来通讯，单个微服务内部高度耦合，服务与服务之间彻底独立，无耦合。提升开发效率，下降开发成本。
• 重写某个服务就至关于重写某个业务的代码，很是简单。
• 服务独立部署，对其余服务不产生影响。
• 微服务在CAP理论中采用的是AP架构，即具备高可用和分区容错的特色。高可用主要体如今系统7x24小时不间断的服务，它要求系统有大量的服务器集群，从而提升了系统的负载能力。另外，分区容错也使得系统更加健壮。

3.二、微服务的不足

• 微服务的复杂度
• 分布式事务：参考《分布式服务架构：原理、设计与实战》第二章完全解决分布式系统一致性的问题
• 服务的划分：领域驱动设计
• 服务的部署：微服务系统须要对每一个系统进行治理、监控和管理等，而每一个服务有大量的配置，还须要考虑服务的启动顺序和启动时机等。微服务是核心；Docker为容器技术，是微服务最佳部署的容器；DevOps是一种部署手段或理念。

四、微服务和SOA的关系

SOA即面向服务的架构，微服务将复杂的业务组件化，实际也是一种面向服务思想的体现。对于微服务来讲，它是SOA的一种实现，可是它比ESB实现的SOA更加轻便、敏捷和简单。

能够看下《分布式服务架构：原理、设计与实战》第一章分布式微服务架构设计原理

五、微服务的设计原则

软件设计每一个版本都在变化，因此软件设计应该是渐进式发展。软件从一开始就不该该被设计成微服务架构，微服务架构当然有优点，可是它须要更多的资源，包括服务器资源、技术人员等。追求大公司所带来的技术解决方案，刻意地追求某个新技术，企图使用技术解决全部的问题，这些都是软件设计的误区。

技术应该是随着业务的发展而发展的，任何脱离业务的技术是不能产生价值的。在初创公司，业务很单一时，若是在LAMP单体架构够用的状况下，就应该用LAMP，由于它开发速度快，性价比高。随着业务的发展，用户量的增长，能够考虑将数据库读写分离、加缓存、加负载均衡服务器、将应用程序集群化部署等。若是业务还在不断发展，这时能够考虑使用分布式系统，例如微服务架构的系统。无论使用什么样的架构，驱动架构的发展必定是业务的发展，只有当前架构再也不适合当前业务的发展，才考虑更换架构。

能够看下《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化

在微服务架构中，有三大难题，那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时，必定要考虑清楚这三个难题，从而选择合适的框架。目前比较流行的微服务框架有Spring社区的Spring Cloud、Google公司的Kubernetes等。为了解决服务故障的传播性，通常的微服务框架都有熔断机制组件。另外，服务的划分没有具体的划分方法，通常来讲根据业务来划分服务，领域驱动设计具备指导做用。最后，分布式事务通常的解决办法就是两阶段提交或者三阶段提交，无论使用哪种都存在事务失败，致使数据不一致的状况，关键时刻还得人工去恢复数据。