微服务架构综述对于现在很多公司，都是用微服务架构作为系统的主要架构，因为其具有高独立，高拓展的特性，此文主要对微服务是什

对于现在很多公司，都是用微服务架构作为系统的主要架构，因为其具有高独立，高拓展的特性，此文主要对微服务是什么，以及微服务使用的一些技术进行简要的综述。

关于系统架构

所谓架构，是一种设计理念，它表示一系列组件模块与它们之间的交互

在历史中，架构也是不断演变的，首先就是最简单的单体架构， 单体架构本质上就是我们日常个人开发使用的，按照业务线垂直划分

在单体架构中，项目直接进行不同模块的开发，所有模块都在一个进程中，这样架构的优势便在于其简单易维护，同时有着很高的性能。然而单体架构代码耦合却会带来调试的复杂性，一个模块的问题可能会影响到其他模块甚至整个系统，模块之间相互影响分工也非常困难。

为了对模块进行解耦与增加分工和模块开发的可能性，垂直应用架构将业务按照不同模块进行垂直划分，不同的业务可以独立的开发维护。

Untitled 1.png 然后在这种架构中，存在着一定的代码耦合(不同业务会涉及相同的功能)，在每个单体业务中，业务模块功能的故障仍然会影响整个业务。

此处的分布式仅是一个狭义上的分布式概念，主要是将公有的业务抽离出来作为单独的业务进行实现，减少了不同业务间的冗余。然而这样的设计会带来毕竟复杂的依赖关系，同时服务模块的独立同样带来了高风险：服务模块出现问题会导致整个系统的崩溃。

在分布式架构的基础上引入服务注册中心，对不同的服务进行一个中心化的调度和管理，引入服务和服务注册的概念。然而这样的架构其实不能很好地满足拓展性：其设计是一个至上而下的过程，服务层的实现要考虑展现层的逻辑

Untitled 2.png

为了实现彻底的服务化，微服务架构诞生，在微服务架构，服务这个概念被进行了高度抽象，不同业务模块之间实现了真正的解耦，不同的业务之间进行完全独立的设计，且具有相当的故障隔离。

Untitled 3.png

当然，在微服务中，我们仍然不能避免它带来的运维观测和安全性上的挑战

相比于SOA，微服务的划分更加精细，可以说SOA是微服务的超集，通常一个SOA任务是可以由多个微服务共同实现的。

微服务实际上更加专注于一个业务的开发，SOA更倾向于一个系统

Untitled 4.png

在微服务中，一个服务即表示了几个运行相同代码的实例，这里一个服务部署多个实例主要方便使用中的负载均衡，通常一组微服务共同实现功能

由于不同服务只实现专一的功能，完整的系统需要服务之间相互通信实现，在实际过程中，服务通常通过http和RPC实现通信。

Untitled 5.png

通常http是文本传输，它具有更好的可读性，而RPC是通过二进制传输，通常具有更好的效率。通常在外网通信中使用htpp，内网中使用RPC

Untitled 6.png

知道了服务之间如果进行通信，那么在代码层面，该如何指定一个目标服务的地址。这里我们使用服务注册与发现。

服务注册发现是一个类似于DNS的中间件，也叫做服务注册中心，通过中心存储服务名到服务实例的映射，来完成服务发现。一个服务上线时，需要在中心处注册，中心对调用者进行调度并分配对应的服务地址，中心可以对服务进行流量控制和负载均衡等调整。