微服务架构学习（一）之微服务架构概览

微服务优点：

• 微服务是继SOA后，最流行的服务架构风格之一。
• 按照微服务对系统进行拆分后，每个服务的业务逻辑都更加简单、清晰。服务之间是松耦合的，模块之间的边界也更加清晰。
• 微服务有效降低了软件项目的业务复杂程度，为小团队独立开发、持续交付和部署打下了良好的基础。

微服务缺点

• 与传统的单一架构相比，微服务架构对团队的组织架构、技术水平、运维能力等方面，都提出了更高的要求。如果没有掌握得当的方法而生搬硬套，微服务架构只会会适得其反
• 在国内外的技术社区中，比较推崇现有开源方案，如"Spring Cloud全家桶"或者阿里开源的"Dubbo"。使用开源框架省却了造轮子的过程，但也降低了我们学习、思考的欲望。
• 已有的微服务资料过于重视微服务的开发，忽略了微服务赖以生存的生态系统：工具链、自动化运维。可以说，离开了这两点的支持，微服务架构将难以落地。

需要掌握技术

• Git
• Maven & Gradle
• Docker & k8s
• Java
• Spring / Spring Boot
• 数据库: 如MySQL
• 消息队列: 如RabbitMQ
• 缓存系统: 如Memcached
• 内存数据库: 如Redis

单块架构的缺点

• 耦合严重：单块服务内的各个逻辑之间，往往缺乏清晰的边界。导致内部耦合严重，正所谓“牵一发而动全身”。
• 维护困难：单快服务包含了过多的业务，代码量严重膨胀。开发人员难免”失焦“，不知道如何下手。
• 团队协作困难：如果多人同时开发同一个单块应用，势必导致代码冲突成为常态，团队协作成本急剧上升。
• 测试困难：单块服务是作为一个整体进行开发、上线的。尽管你只对Ａ功能进行了修改，但难免会影响Ｂ功能。随着单块应用的愈发膨胀，测试工作量会提升数倍。

微服务架构的优点

• 低耦合：在单块服务中，不同业务的逻辑耦合在一起。做微服务拆分后，微服务内只包含有限的业务逻辑，耦合也随之大大降低。
• 易维护：微服务内部只包含单一业务逻辑，功能更为集中，更容易开发人员聚焦问题和修改。
• 适合团队协作：拆分为微服务后，每个服务中涉及的代码和功能更少，可以将不同微服务划分给不同团队甚至个人负责。各司其职后，有效降低了开发和代码冲突，使得其适合团队协作。
• 测试成本低：在单块服务中，哪怕只改动了一点点代码，也需要对整个巨无霸服务进行测试。微服务拆分后，功能的修改，只需要涉及改动的个别微服务进行测试，有效降低了测试工作量。
• 易横向拓展：在单块服务时代，巨无霸服务已经占用了大量资源，机器的配置已经很高，若要再单独部署一个结点做负载均衡，成本会非常很高，所以多数情况下，都是通过纵向拓展的方式提升系统性能（如加内存，换个更好的cpu）。采用微服务拆分后，各个微服务占用的资源更少，可以轻松的通过增加节点的横向拓展方式，提升系统性能。更进一步的说，根据阿姆达尔定律，微服务拆分后，各个微服务对性能的要求并不一致，可以优先拓展那些具有性能短板的微服务，有效降低了拓展成本。
• 技术选择更多样：由于微服务是各自独立的进程。各个团队可以根据自己的需要选择不同的技术方案。然而在实践中，我并不推荐这么搞，这会在后面技术选型时展开。
• 加快迭代速度：上面已经提到，微服务低耦合、易维护、适合团队协作、测试起来成本更低，也更易于横向拓展。采用微服务架构后，可以显著的提升迭代速度。

微服务整体架构

基础设施层

• 微服务是后端服务，最终一定要部署在基础设施的某台机器上。基础设施层可以是自运维的服务器或机架，也可以选用云计算的虚拟机。
• 在这一层，我们重点关注底层“物理资源”1的可用性及调整：计算资源（CPU 和 GPU）、存储资源(内存、硬盘)、网络资源（交换机、路由）。对这些基础设施的维护，或者是直接在机房维护，或者是操作云平台的API。
• 举几个例子：大促前预估系统容量不足，我们要加半个机架的机器；直播平台今晚要来大V，预计带宽不足，要增加带宽。这些都是在基础设施层要关注的内容。

运维平台层

• 对于后端服务的运维工作，持续交付是最重要的能力。由于微服务数量众多，一般需要构建一个持续交付系统，来完成微服务的自动运维，如微服务的初始化、发布、回滚、扩容。
• 采用微服务架构后，上线的次数、频率都会显著提升，这就需要一个上线的镜像版本管理系统，记录上线的镜像版本。在微服务架构中，一般采用容器技术来实现微服务的自动运维。
• 容器是轻量级资源，隔离能力相对较弱，我们需要对容器资源进行监控，调度和管理。举个例子：我们有三台物理机，现在物理机Ａ和C各运行了20个容器，物理机Ｂ运行了22个容器，假设每个容器的资源占用完全一致，那么资源调度系统会自动地，将B的两个的容器调整到物理机Ａ和Ｃ上。

微服务设施层

• 假设服务A需要调用服务B，那么A服务如何获取服务B的地址(例如IP和端口)呢？在传统的单块架构中，服务数量很少，尚可采用同在配置中写死IP、端口的方法来解决这个问题。但在微服务时代，面对动辄成百上千的微服务，这种做法将不再可行。因此，如何自动注册、发现微服务的多个实例，是架构必须解决的核心问题。
• 微服务拆分后，我们的系统从单机演化为分布式系统，为了防止分布式系统的雪崩效应2、微服务设施需要有的熔断和限流的能力。
• 面对众多的微服务，逐一修改配置的方式显得更加笨拙，我们需要有一个中央配置平台，快速完成微服务的配置修改。
• 前面已经提到，微服务的分布式架构，会加大调试难度，所以日志的收集和预警显得更加重要，同时，我们可以根据业务日志来进行一些监控预警，这和平台层的容器监控预警是不一样的。
• 微服务需要集成一些后端组件，如数据库、消息队列、缓存等。

业务服务层：

在提供了微服务的基础设施后，我们可以放手开发各个微服务了。业务服务层是一些“基础微服务”或“业务微服务”，他们“各司其职”，服务之间的耦合应当做到最低。

接入网关层：

微服务面向的“用户”，一般是Web、移动端、PC端等。出于用户体验的考量，服务端提供给客户端的的接口应当尽量实现结果聚合，减少请求次数。因此，一般要设置一层接入网关，他负责调用业务微服务A B C等，完成结果聚合后，一并返回给客户端。

标签：容器,服务,运维,单块,概览,之微,耦合,架构
来源： https://www.cnblogs.com/longronglang/p/14726955.html