一、微服务概述
微服务架构是团队面对互联网产品爆发式增长的最优选择,要解决的是快速迭代、高可靠和高可用等问题,把复杂度很高的产品拆分成一些较小的模块,并遵循康威定律,每一个模块用5-9个小团队来维护,这样可以减少沟通成本,提高协作效率,更好地实现快速迭代和弹性扩展。
既没有规模又不需要太多变化的业务,如果采用微服务架构改造,引入各种复杂性,比如部署工作量的增加、复杂链路的监控难题,这就是为微服务而微服务,只会得不偿失。
- 早期的单块系统会遇到很多问题,基于此,微服务架构应运而生;
- 微服务是一系列协同工作的、小而自治的服务,服务之间使用RESTFul或RPC接口集成;
- 微服务的优点:
- 弹性好
- 技术异构性
- 扩展性好
- 简化部署
- 与组织结构相匹配
- 可复用性好
- 易于重构
- RESTFul + Docker + K8S 是一个很流行的微服务架构技术栈;
- RESTFul接口通过四个HTTP动词,对服务端资源进行操作;
- RPC,远程过程调用就像调用本地函数那样,调用服务端函数;
- RESTFul接口简单直接、但性能不好;RPC需提供客户端、但效率高
接口封装常用工具:
- flask-restful
- grpc
1、微服务优点
2、缺点
3、适不适合用微服务
4、微服务架构使用时机
5、业务模块
6、单体部署(商品中心模块)
7、单体部署改造:微服务架构
二、分布式 v.s. 微服务
从实践的角度来看,微服务架构通常是分布式服务架构,反之则未必成立。所以,选择微服务通常意味着需要解决分布式架构的各种难题。
-
分布式:分散压力。
-
微服务:分散能力。
分布式:不同模块部署在不同服务器上;
- 作用:分布式解决网站高并发带来问题;
集群:相同的服务;
- 多台服务器部署相同应用构成一个集群;
- 作用:通过负载均衡设备共同对外提供服务;
微服务[找到服务/微服务网关open API];
- 架构设计概念,各服务间隔离(分布式也是隔离),自治(分布式依赖整体组合)其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行;