微服务概念
微服务是系统架构上的一种
设计风格。将一个原本独立的
系统拆分成多个小型服务,这些小型服务都在
各自独立的进程中运行,服务之间通过
基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些
耦合度较高的业务功能进行构建。并且每个服务都维护着
自身的数据存储、业务开发、
自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础,所以这些
微服务可以使用不同的语言来编写。
特点
1. 是一种设计风格
2. 将一个独立的系统拆分成多个小型服务,各自独立运行。
3. 服务间基于HTTP的RESTful API进行通信。
4. 能够达到解耦的目的。
5. 各自维护自身的数据存储,能更加方便进行自动化测试。
与传统单体系统的比较
传统单体系统特点:通常将一个复杂庞大的系统构建一个单体项目。通常将需求分为三个主要部分:数据库、服务端处理、前端展现。在业务发展初期,由于所有的业务逻辑在一个应用中,开发、测试、部署都还比较容易且方便。但是,随着企业的发展,系统为了应对不同的业务需求会不断为该单体项目增加不同的业务模块;同时随着移动端设备的进步,前端展现模块已经不仅仅局限于Web的形式,这对于系统后端向前端的支持需要更多的接口模块。单体应用由于面对的业。 不断扩大的需求会使得单体应用变得越来越臃肿。单体应用的问题就逐渐凸显出来,由于单体系统部署在一个进程内,往往我们 修改了一个很小的功能,为了部署上线会影响其他功能的运行。
并且,单体应用中的这些功能模块的 使用场景、并发量、消耗的资源类型都各有不同,对于资源的利用又互相影响,这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。但是随着系统的发展, 维护成本会变得越来越大,且难以控制。
我们将系统中的不同功能模块拆分成多个不同的服务,这些服务都能够独立部署和扩展。由于每个服务都运行在自己的进程内,在部署上有稳固的边界,这样每个服务的更新都不会影响其他服务的运行。同时,由于是独立部署的,我们可以更准确地为每个服务评估性能容量 ,通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置,以及给出较为准确的系统级性能容量评估。
微服务框架的选择
- 服务治理: 阿里巴巴开源的**Dubbo**和当当网在其基础上扩展的**DubboX**、Netflix的Eureka、Apache的Consul等。
- 分布式配置管理: 百度的Disconf、Netflix的Archaius、360的QConf、Spring Cloud的Config、淘宝的Diamond等。
- 批量任务: 当当网的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等。
- 服务跟踪: 京东的Hydra、Spring Cloud的Sleuth、Twitter的Zipkin等。
spring Cloud的出现,可以说是对微服务架构的巨大支持和强有力的技术后盾。它不像我们之前所列举的框架那样,只是解决微服务中的某一个问题,而是一个解决微服务架构实施的**综合性解决框架**,它整合了诸多被广泛实践和证明过的框架作为实施的基础部件,又在该体系基础上创建了一些非常优秀的边缘组件。