java|《深入理解Spring Cloud与微服务构建》第1章微服务简介 json|数据库

2019独角兽企业重金招聘Python工程师标准>>>
文章图片

1、单体架构及其存在的不足 1.1、单体架构简介
一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译打包，部署在一台服务器上。
1.2、单体架构存在的不足

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

1.3、单体架构使用服务器集群及存在的不足
用负载均衡服务器分发高并发的网络请求，用户访问被分派到不同的应用服务器，应用服务器的负载不再成为瓶颈，用户量增加时，添加应用服务器即可。通过添加缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的，但是仍然由少数读操作是从数据库读取的，例如缓存失效、实时数据等。当有大量的读写操作时，将数据库进行读写分离是一个不错的选择，例如MySQL的主从热备份，通过相关配置可以将主数据库服务器的数据同步到从数据库服务器，实现数据库的读写分离，读写分离能够改善数据库的负载能力。
这种架构有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善了系统的性能，但是依然没有改变系统为单体架构的事实，此时存在的不足之处如下。

文章图片

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

【java|《深入理解Spring Cloud与微服务构建》第1章微服务简介】所以，单体架构已经不能满足复杂的业务和海量的用户系统，改变单体架构势在必行。
2、微服务

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

2.1、微服务单元按业务来划分
按业务划分的微服务单元独立部署，运行在独立的进程中。这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。
2.2、微服务通过HTTP来互相通信
微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制，更多的时候是使用RESTful API的。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效，并且这种通信机制与平台和语言无关。
服务与服务之间也可以通过轻量级的消息总线来通信，例如RabbitMQ、Kafaka等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。
它们通信的数据格式一般为JSON、XML，与语言、平台、通信协议无关。JSON格式的数据比XML轻量，并且可读性也比XML好。
2.3、微服务的数据库独立
一个典型的微服务架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用；还有一个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。每个服务的数据库不一定都相同，它们所使用的数据存储技术需要根据业务需求来选择。
2.4、微服务的自动化部署
自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，部署过程的每一步自动化，提高软件的质量。
2.5、服务集中化管理
微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如Spring Cloud 采用Eureka来注册服务和发现服务，另外，Zookeeper、Consul等都是非常优秀的服务集中化管理框架。
2.6、分布式架构
微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局ID等，而单体系统不需要考虑这些复杂性。
另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。
2.7、熔断机制
为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。当某服务出现故障，请求失败次数超过设定的阀值之后，该服务就会开启熔断器，之后该服务不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。
3、微服务的优势和不足 3.1、微服务的优势

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

3.2、微服务的不足

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

4、微服务和SOA的关系 SOA即面向服务的架构，微服务将复杂的业务组件化，实际也是一种面向服务思想的体现。对于微服务来说，它是SOA的一种实现，但是它比ESB实现的SOA更加轻便、敏捷和简单。
可以看下《分布式服务架构：原理、设计与实战》第一章分布式微服务架构设计原理
5、微服务的设计原则软件设计每个版本都在变化，所以软件设计应该是渐进式发展。软件从一开始就不应该被设计成微服务架构，微服务架构固然有优势，但是它需要更多的资源，包括服务器资源、技术人员等。追求大公司所带来的技术解决方案，刻意地追求某个新技术，企图使用技术解决所有的问题，这些都是软件设计的误区。
技术应该是随着业务的发展而发展的，任何脱离业务的技术是不能产生价值的。在初创公司，业务很单一时，如果在LAMP单体架构够用的情况下，就应该用LAMP，因为它开发速度快，性价比高。随着业务的发展，用户量的增加，可以考虑将数据库读写分离、加缓存、加负载均衡服务器、将应用程序集群化部署等。如果业务还在不断发展，这时可以考虑使用分布式系统，例如微服务架构的系统。不管使用什么样的架构，驱动架构的发展一定是业务的发展，只有当前架构不再适合当前业务的发展，才考虑更换架构。
可以看下《大型网站技术架构——核心原理与案例分析》第1章：大型网站架构演化
在微服务架构中，有三大难题，那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时，一定要考虑清楚这三个难题，从而选择合适的框架。目前比较流行的微服务框架有Spring社区的Spring Cloud、Google公司的Kubernetes等。为了解决服务故障的传播性，一般的微服务框架都有熔断机制组件。另外，服务的划分没有具体的划分方法，一般来说根据业务来划分服务，领域驱动设计具有指导作用。最后，分布式事务一般的解决办法就是两阶段提交或者三阶段提交，不管使用哪一种都存在事务失败，导致数据不一致的情况，关键时刻还得人工去恢复数据。

转载于:https://my.oschina.net/lienson/blog/3032274