学习笔记----微服务开篇

前言

博客只是自己为了记录学习过程，伟人都说了好记性不如烂笔头，所以我也准备把最近的学习过程记录一下，水平有限还请望多多指教

一，微服务

1，何为微服务：

一种系统架构思想（Microservice Architecture，MSA），既然是一种思想那么它和语言、框架、工具、服务器环境无关...

它提倡将传统的单体系统按照业务划分成多个职责单一、且可独立运行的服务，服务之间互相协调、互相配合，为业务提供技术支持，最终实现商业价值。

2，微服务架构的优势：

（1）服务之间逻辑清晰职责单一有利于开发效率

（2）服务架构灵活，支持多技术多语言实现

（3）有利于提高服务的并发能力

（4）有利于服务的扩展与收缩实现服务的高可用

（5）独立部署有利于迭代升级

3，微服务架构的不足：

（1）系统复杂度提高，对开发人员技术要求以及工作量明显增加

（2）分布式系统数据强一致性困难，只能确保系统数据一致性机制

（3）多服务导致系统的整体维护、故障诊断定位以及搭建成本提高

（4）多服务系统测试变得复杂

二，微服务的微与服务

1，微：

  微服务核心主体是“微”，微不能单理解成功能或者微小的系统，它应该意指的是功能单一或者业务的紧密的服务。

（1）为什么需要微？

  先看一张图：

        

               

  依传统的电商业务单体架构为例，包含了所有的业务逻辑和场景系统架构比较庞大，代码难以扩展和维护；  如果时间久前后接手的人多在加上互联网先上线后扩展的精神，必然造成代码耦合度太高代码冗余，

  业务逻辑的修改基本上是牵一发而动全身，甚至会出现改不动、不敢动的情况。

（2）该如何对传统单体架构如何微

 传统单体架构其实这种方式也是另一种颗粒维度的“微”，只是这种方式的微算得上是微乎其微。 本着不破不立的原则那就一个字拆，要简单粗暴一点的方式就直接按照业务点与功能点为基础

     

               

  . 按照业务点拆分：

  以业务的密切程度为基本原则，关联密切的业务拆分为一个微服务，较独立的业务单独拆分为一个微服务。

. 按照功能点拆分：

一个功能服务一个功能数据库一个功能服务服务的原则进行拆分，做到服务模块职责单一，功能之间可以做到高内聚低耦合，解耦平行功能的调用方便服务的扩展

PS：这种简单粗暴的方式不是很推荐毕竟代价太大， 拆分姿势肯定不会如此简单，还需要结合实际情况来考虑如：人员情况、开发/维护成本、系统侧重点、业务变动频率.....

2，服务

微是整体架构的指导思想，而服务就是微的具体实现。在架构整体的微颗粒度划分明确时，相应的服务支撑也会随之确定

按类型大致分为：

（1） 功能服务：

如： API网关服务， 服务调用方式，服务注册与发现，消息事件总线服务等等。

（2）业务服务：

如：身份服务，商品服务，订单服务，支付服务等等。

三，微服务设计原则

1，单一职责

每个微服务只需要实现自己的业务逻辑，尽可能做到高内聚低耦合，必要时略有冗余并无不可

2，服务高度自制

服务能够独立开发，部署，运维，自身拥有一套完整流程

3，弹性设计

设计具有隔离、容错、降级的服务，满足系统高可用性的要求

4，无状态服务

无状态服务原则并不是说在微服务架构的数据里不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据

也就相应的迁移到对应的“有状态数据服务”中。数据模块单独提取，服务尽量只考虑业务拓展不考虑数据的持久化

四，关于微服务架构以及技术选择

    

API网关：

API网关是内部微服务的对外唯一入口，主要起到了隔离内外网、负载均衡、身份验证、路由、限流等作用

常用技术：Kong、Ocelot、Nginx、Apache APISIX、YARP 等

服务注册与发现：

负责应用服务注册发现，同时监控应用服务接口运行情况，用于服务的健康检查

常用技术：Consul、etcd、ZooKeeper 等

身份认证中心：

架构访问统一身份认证，鉴别访问权限和身份与网关API”实现安全访问、限流等功能、

常用技术：IdentityServer4

服务调用：服务之间的相互调用

常用方式：WebAPI、gRPC

消息事件总线：

用来管理所有的事件的一种机制就称作为事件总线，包括事件发布，事件存储，事件订阅，事件处理的统称，将微服务系统各组件之间进行解耦

常用技术：RabbitMQ、Kafka

瞬态故障处理：

应对被调用端出现宕机，和超时两种情况出现的一种策略机制

常用技术： Polly

分布式系统追踪：

帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题

常用技术： Prometheus

分布式事务：

为了保证系统架构数据一致性问题，微服务使用分布式（柔性）事务，在业务过程中可以容忍一定时间内的数据不一致

让数据最终能够达到一致的状态

常用技术：CAP

分布式日志：

负责记录系统敏感信息，便于代码BUG问题的定位修改

常用技术： ExceptionLess

分布式缓存：

API网关和数据库层面的缓冲区域，用来减少对数据库的查询压力，提高系统的吞吐量

常用技术：Redis

分布式锁：

主要用来解决分布式环境当中多个进程之间的同步控制,防止分布式系统中的多个进程之间相互干扰，让进程对资源进行有序的访问与操作,

防止造成"脏数据"的后果

常用技术：RedLock.NET

消息队列：

布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题

常用技术：RabbitMQ

下一篇，，网关系统的搭建

--------to be continue --------