《微服务架构实战》读书笔记(一)---微服务概述

微服务架构实战读书笔记(一)---微服务概述

什么是微服务

​ 现在微服务概念十分火热，到底什么是微服务？与之前的架构有啥区别？

​ 微服务是一种软件架构模式，可以把它理解为三层架构mvc一样，同样只是一种人们为了应对业务规模的迅速扩大，从而总结出来的一种架构模式

​ 它将以往的单机MVC架构中的业务，抽离出公共的服务单独部署，实现代码的可复用性，服务和服务之间的耦合度降低。并且数据库也抽出，一个服务都有自己单独的数据库，耦合降到最低。在可扩展性上提高了很多，有了优点也不可避免带来了其他缺点

优点

• 开发简单，独立性高
• 每个服务可以选择不同语言，技术选用灵活
• 服务无依赖
• 服务可以按需扩展集群
• 一个服务挂了不会影响其他，可用性高
• 选择轻量api通信
• 服务小而精

缺点

• 运维困难，如何有效管理庞大的服务是个困难
• 部署依赖
• 通信成本，网络延迟啥的，接口不可用怎么办
• 数据一致性，分布式自带的问题
• 测试成本
• 监控问题
• 沟通成本
• 可能重复工作

微服务的主要难点在于，系统的设计，服务管理，运维。随着系统的复杂，有可能抽象化程度不高，导致服务重复化，而且庞大的服务如何有效的管理是个巨大问题，监控服务到性能。

架构的演变

单机架构

​ 最开始的单机架构MVC，大家最熟悉

​ controller->service->dao->db

​ 这里有个很明显问题是如果项目中一个业务模块出了问题会导致整个项目崩溃，无法对外提供服务

第一步切分

​ 每个业务模块单独部署

​ 网页访问不同的业务模块，一个业务挂了不会导致整个系统挂了

​ 现在存在的问题是前端调用接口数量具有管理

服务化

​ 在业务和网页中间加一个api网关，可以理解为Nginx，用这个来管理接口

​ 然后服务之间通过RPC远程调用进行访问

​ 但是需要调用RPC需要个注册中心，得让消费者知道服务提供者在什么地方，这个时候需要zookeeper充当注册中心

微服务的可扩展性

​ 性能可扩展:因为服务可以按需扩展集群

​ 可用性扩展:cap理论，一般采用ap，选择可用性和分期容错性，牺牲强一致性，保证最终一致性

​ 维护可扩展:使用自动化平台工具，实现自动化部署更新

​ 成本可扩展:先有组件可以重用，使用行业标准容易招人

微服务和SOA区别

​ 网上很多资料对这块都是很模糊，我也不见得能把握精髓吧，我个人理解划分服务的粒度不同

​ 微服务本身也是SOA一个提升

​ SOA对服务的划分还是比较粗，而微服务更加细了

常见的微服务组件

• 服务注册
• 服务发现
• 负载均衡
• 服务网关
• 配置中心
• API管理
• 框架集成
• 分布式事务
• 调用链
• 支撑平台

常用的微服务框架

​ dubbo

​ Spring cloud

​