微服务架构介绍
微服务架构是一种架构概念
通过将功能分解到离散的服务中已实现对解决方案的解耦， 降低耦合性
- 概念：把一个大型的 单个应用程序和服务拆分为数个甚至数十个支持的微服务
- 定义：围绕业务领域创建应用，不同应用可以进行独立开发，管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能， 使产品交付变得更加简单
- 本质：用一些功能比较明确、业务比较精炼的服务取解决更大更实际的问题
传统开发模式和微服务的区别
传统开发：即单体开发，所有的功能在一个tar包里
优点：
- 开发简单，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理和调用消耗
缺点
- 开发效率低：开发都在一个项目改代码，相互等待，冲突不断
- 维护难：功能严重耦合，不知如何下手
- 不灵活：构建时间长，任何小的问题都可能导致整个应用服务挂掉
- 稳定性差：一个微小的问题都可能导致整个应用挂掉
- 扩展性差：无法满足高并发下的业务需求
系统架构遵循的三个标准和业务驱动力
- 提高敏捷性
- 提升用户体验
- 降低成本
基于微服务的架构
目的：有效的拆分应用，实现敏捷开发和部署
微服务的具体特征
- 独立的服务共同组成系统，实现组件化
- 单独部署，跑在自己的进程中
- 每个服务为独立的业务开发
- 分布式管理
- 强调隔离性
微服务的标准
- 分布式组成的系统
- 按照业务划分，而不是按照技术划分组织
- 做有生命的产品而不是项目
- 强服务个体和若通信
- 自动化运维
- 高度容错性
- 快速演化和迭代
- 去中心化
SOA和微服务的区别
soa 架构特点：
- 系统集成，将原本网状结构，通过ESB总线，梳理成星形结构 这一步解决的核心问题是【有序】
- 系统的服务化： 把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
- 业务的服务化： 以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
- soa 喜欢重用，微服务喜欢重写
- soa 看重水平业务，微服务看重垂直业务
- soa 喜欢自上而下，微服务喜欢自下而上
主要区别
微服务实践
要实际应用微服务，要解决以下四点
- 客户端如何访问微服务
- 每个微服务之间如何通信
- 如此多的微服务，如何实现
- 服务挂了如何解决（备份方案，应急机制）
客户端如何访问这些服务
一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway ，他的作用：
- 提供统一的服务入口，让微服务对前台透明
- 聚合后台服务，节省流量，提上性能
- 提供安全，过滤， 限流等API管理功能
每个服务之间如何通信
所有的微服务都是独立进程跑在独立机器上，所以服务间的通信就是IPC（inter process communication） 通常有以下两种方式
同步调用
- REST
- RPC(Thrift, dubbo)
异步调用
- kafka
- notify
- metaQ
同步调用比较简单，一致性强，但是容易出现调用问题，新能体验上会差点，而异步调用的方式在分布式系统中有广泛的应用，能减服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时保证调用方的服务体验，继续干自己的事情，不至于被后台性能拖慢
一般rest基于http，更容易实现，更容易被接受，各个语言都能支持，对客户端没有要求，只是分装了h’t’t’p的sdk就能调用
rpc也有自己的优势，传输效率更高效，安全更可控
如此多的服务如何实现
在微服务架构中，一般每个组件都有多个拷贝用来做负载均衡，一个服务随时可能下线，也可能随时面临访问压力增加新的服务节点，服务之间如何感知，服务如何管理？
这就是微服务发现问题
微服务发现一般有两类做法
通过zookkeeper等类似框架做服务注册信息的分布式管理，当服务上线时，服务提供自己的服务信息注册到zookeeper,并且通过心跳维持长链接，调用这通过zk寻址根据定制算法找到一个服务，当服务下线时，zk会发通知给客户端
- 通过客户端做， 优点是架构简单，扩展灵活，只对服务注册器依赖，缺点是客户端要维护所有调用服务地址，有技术难度，一般大公司都有成熟的技术框架支持比如dubbo
- 通过服务端做，优点是简单所有服务对前台调用方透明
服务挂了，如何解决
- 重试
- 限流
- 熔断
- 负载均衡
- 降级（本地缓存）