本文图文整体介绍微服务架构，为后续微服务架构系列讲解奠下基础。

微服务架构（Microservice Architecture）是一种架构方式，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年可以说是微服务的元年，越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，进一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。

Martin Fowler是国际著名的OO专家，是当今世界软件开发领域最具影响力的五位大师之一，是敏捷开发方法的创始人之一，Fowler大力倡导业内最先进的软件开发技术，在面向对象分析设计、UML、模式、软件开发方法学、XP(Extreme Programming，极限编程而非操作系统)、重构等方面，都是世界顶级的专家，现为ThoughtWorks(一家全球软件设计与定制领袖企业)的首席科学家。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍： 《重构－改善既有代码的设计》(Refactoring: Improving the Design of ExistingCode) 、《UML精粹：标准对象建模语言简明指南》(UML Distilled：A Brief Guide to the Standard Object Modeling) 、《分析模式：可重用的对象模型》(Analysis Patterns：Reusable Object Models)、《企业应用架构模式》(Patterns of Enterprise Application Architecture)等。关于微服务有句很经典的话：一解释就懂，一问就不知，一讨论就打架(http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means)。

ThoughtWorks官网这样描述微服务：The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.

从ThoughtWorks官方的描述可以看出微服务的特点：

1.一系列独立的服务共同组成系统
2.单独部署，跑在自己的进程中
3.每个服务为独立的业务开发
4.分布式管理
5.非常强调隔离性

我们先来看一下架构的演进图

正如上图文章所描述的Monolithic（单体式开发）即传统的web开发方式，所有的功能打包在一个 WAR或Jar包里，基本没有外部依赖，部署在一个服务器（Tomcat，Jetty，JBoss，WebLogic）里，包含了Controller/Action，Service， PO/DAO，Viewer/UI等所有逻辑。

优点

①开发简单，集中式管理
②基本不会重复开发
③功能都在本地，没有分布式的管理和调用消耗

缺点

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断
2、维护难：代码功功能耦合在一起，新人不知道何从下手
3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时
4、稳定性差：一个微小的问题，都可能导致整个应用挂掉
5、扩展性不够：无法满足高并发下的业务需求

常见的系统架构遵循的三个标准和业务驱动力

1、提高敏捷性：及时响应业务需求，促进企业发展
2、提升用户体验：提升用户体验，减少用户流失
3、降低成本：降低增加产品、客户或业务方案的成本

SOA（Service-Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA和微服务的区别

1、SOA喜欢重用，微服务喜欢重写

SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(Enterprise Service Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术、语言和框架，然后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。API gateway模式不等同于Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

2、SOA喜欢水平服务，微服务喜欢垂直服务

SOA设计喜欢给服务分层(如Service Layers模式)。 我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求所有的服务都通过这个Entity服务层来获取数据。 这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。

而每个微服务通常有它自己独立的data store。 我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。 类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。 在SOA设计模式中这种情况通常会用到Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、SOA喜欢自上而下，微服务喜欢自下而上

SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理所有的服务，包括集中管理业务逻辑、数据、流程、schema等等。 它使用Enterprise Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。 模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。SOA架构适用于TOGAF之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的快速确认业务需求、快速开发迭代。

---

微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

用《The art of scalability》一书中提到的scale cube来更现象理解如何拆分。

微服务的特点

1.分布式服务组成的系统
2.按照业务，而不是技术来划分组织
3.做有生命的产品而不是项目
4.强服务个体和弱通信（ Smart endpoints and dumb pipes ）
5.自动化运维（ DevOps ）
6.高度容错性
7.快速演化和迭代

微服务的优点

复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高。

微服务的缺点或者说是挑战

多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，重复工作，性能监控等。

微服务架构方案

微服务有很多解决方案和框架，比较流行的是Spring Cloud，Spring Cloud是基于SpringBoot的一整套实现微服务的框架，提供了微服务开发所需的网关、服务发现、配置管理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

上面的架构图中Eureka从2.x开始闭源了

不过国内很多企业依然使用Eureka做注册中心，其实可以用Consul等替换。

Feature	euerka	consul	zookeeper	etcd
服务健康检查	可配支持	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳
多数据中心	—	支持	—	—
kv 存储服务	—	支持	支持	支持
一致性	—	raft	paxos	raft
cap	ap	ca	cp	cp
使用接口(多语言能力)	http（sidecar）	支持 http 和 dns	客户端	http/grpc
watch 支持	支持 long polling/大部分增量	全量/支持long polling	支持	支持 long polling
自身监控	metrics	metrics	—	metrics
安全	—	acl /https	acl	https 支持（弱）
spring cloud 集成	已支持	已支持	已支持	已支持

当然对于微服务每个人的看法都不同

架构可以灵活多样

再比如网易云给出的微服务架构方案

具体的架构按需求去设计，其中常用的组件/模块/脚手架如下

网关: Spring Cloud Gateway，Zuul 2，Kong
注册中心: Eureka(x)，Nacos，Spring Cloud Consul，Zookeeper
服务调用: Feign(x)、OpenFeign、Dubbo RPC
认证授权: CAS、Spring Cloud Security + oauth2.0
配置中心: Spring Cloud Config，Nacos Config
负载均衡: Ribbon，LoadBalancer
熔断、服务降级、限流: Netflix Hystrix(x)，Sentinel
链路跟踪: Sleuth，Zipkin，Skywalking
分布式事务: Seata
日志管理: ELK，EFK
事件、消息总线: Spring Cloud Bus
(x)表示闭源或被淘汰了。

微服务架构是核心，devops和docker是工具，是手段。

最后附上比较常见的有六种微服务架构设计模式。

1.聚合器微服务设计模式

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2.代理微服务设计模式

聚合模式的一个变种，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

3.分支微服务设计模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链。

4.链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。

5.数据共享微服务设计模式

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。

6.异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。

本文从网上收集很多资料整理而成，仅供学习研究使用。

参考资料：
https://yq.aliyun.com/articles/2764
https://www.cnblogs.com/imyalost/p/6792724.html
https://blog.csdn.net/zhoutaochun/article/details/84946028
https://blog.csdn.net/wujian_csdn_csdn/article/details/81701320
https://blog.csdn.net/chenghuaying/article/details/81205400
https://blog.csdn.net/w1014074794/article/details/88177857

---

本文由：分享录(https://www.xubingtao.cn) 、作者： xbt 发表，转载请注明来源：微服务架构[初识微服务]