1、单体架构存在的问题
(1)复杂性高:项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起整个项目非常复杂.
(2)技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成应用用程序的技术债务,并且越积越多。
(3)部署频率低:随着代码的增多,构建和部署的时间也会增加。而在单体应用中,每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
(4)可靠性差:某个应用Bug,例例如死循环、OOM等,可能会导致整个应用的崩溃。
(5)扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
(6)阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成员都必须使用相同的开发语言和框架,要想弓引入新框架或新技术平台会非常困难。
2、什么是微服务
将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
特点：
(1)每个微服务独立运行在自己的进程中。
(2)系列独立运行的微服务共同构建起整个系统。
(3)每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理、用户管理等。
(4)微服务之间通过一些轻量的通信机制进行通信,例例如通过 RESTFUL API进行调用。
(5)可以使用不同的语言与数据存储技术。
(6)全自动的部署机制。
优点：
(1)易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。
(2)单个微服务启动较快:单个微服务代码量较少,所以启动会比较快。
(3)局部修改容易部署:单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
(4)技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库 MYSQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用 Node.js开发。
(5)按需伸缩:可根据据需求,实现细粒度的扩展。例如,系统中的某个微服务遇到了瓶颈,可以结台这个微服务的业务特点点,增加加内存、升级CPU或者是增加节点。
设计原则：
单一职责原则
指的是一个单元(类、方法或者服务等)只应关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅地开发、更敏捷地交付。单一职责原则是 SOLID原则之一。有兴趣的读者可前往htps∥en. wikipedia. org/wiki/
服务自治原则
服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中,服务是独立的业务单元,应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署,都应当可以独立运行,而不应该依赖其他的服务。
轻量级通信机制
微服务之间应该通过轻量级的通信机制进行交互。笔者认为,轻量级的通信机制应具备两点:首先是它的体量较轻;其次是它应该是跨语言、跨平台的。例如我们所熟悉的REST协议,就是一个典型的“轻量级通信机制”;而例如Java的RMI则协议就不大符合轻量级通信机制的要求,因为它绑定了Java语言。
微服务架构中,常用的协议有REST、AMQP、 STOMP、MQTT等。
微服务粒度
微服务的粒度是难点,也常常是争论的焦点。应当使用合理的粒度划分微服务,而
不是一味地把服务做小。代码量的多少不能作为微服务划分的依据,因为不同的微服务本身的业务复杂性不同,代码量也不同
Spring Cloud有以下特点:
。约定优于配置。
适用于各种环境。开发、部署在 PC Server或各种云环境(例如阿里云、AWS等)
均可隐藏了组件的复杂性,并提供声明式、无xml的配置方式。
开箱即用,快速启动。
。轻量级的组件。 Spring Cloud整合的组件大多比较轻量。例如 Eureka、Zul,等等,
都是各自领域轻量级的实现。
。组件丰富,功能齐全。 Spring Cloud为微服务架构提供了非常完整的支持。例如,配
置管理、服务发现、断路器、微服务网关等。
。选型中立、丰富。例如, Spring Cloud支持使用 Eureka、 Zookeeper或 Consul实现服
务发现。
。灵活。 Spring Cloud的组成部分是解耦的,开发人员可按需灵活挑选技术选型。
中
