微服务架构

一、微服务产生的背景

        微服务是一种软件的架构风格，这种设计风格是随着软件系统架构的演进而逐渐诞生的。而软件系统架构演进迭代的宗旨都是为了解决和优化人们在软件开发、使用与维护中遇到的各个方面的问题，简单总结为三个阶段：

        1.1 单体架构
                概念：单体架构是一种将所有功能打包在一个容器中运行的设计风格，一个实例中集成了一个系统的所有功能；
                优点：易开发、易调试、易部署；
                缺点：可靠性差、多人共同开发一个项目不易协同、后期升级维护困难，牵一发而动全身；

        1.2 面向服务架构
                概念：是一种分布式服务架构的常见方式，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义明确的接口和协议联系起来，进而实现跨服务单元/系统交互的能力；
                优点：耦合性低、独立性高、可重用；
                缺点：随着大型组织或公司对大规模弹性部署和敏捷开发的需求，面向服务架构的设计方式难以满足各种场景的需求。同时随着虚拟化技术和容器技术的不断发展，持续交付方法论的逐步推广，微服务架构逐渐产生。

        1.3 微服务架构
                概念：专注于单一责任与功能的小型功能区块（服务）为基础，服务之间相互协调、相互配合，每个服务都运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相传输数据，每个服务都围绕具体业务进行构建，并且能够被独立部署。
                优点：松耦合、独立开发、独立部署，服务可以使用不同的语言开发。
                微服务比面向服务架构的优势：复用率更高；响应速度更快；弹性扩展；支持异构

二、微服务要解决的问题

        1）服务划分
        2）服务注册与调用
        3）延迟队列
        4）服务熔断处理
        5）缓存设计
        6）分布式事务实现

三、CAP原理

        C：Consistency
        即一致性，访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。

        A：Availability
        即可用性，所有的节点都保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

        P：Partiton tolerance
        即分区容忍性，这里的分区是指 络意义上的分区。由于 络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

四、BASE理论简介

        BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

五、RPC原理

        RPC(Remote Procedure Call Protocol)——远程过程调用协议，它是一种通过 络从远程计算机程序上请求服务，而不需要了解底层 络技术的协议。RPC协议假定某些传输协议的存在，如TCP/IP或UDP，为通信程序之间携带信息数据。RPC将原来的本地调用转变为调用远端的服务器上的方法，给系统的处理能力和吞吐量带来了近似于无限制提升的可能。在OSI 络通信模型中，RPC跨域了传输层和应用层。RPC使得开发包括 络分布式多程序在内的应用程序更加容易。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92005 人正在系统学习中