什么是微服务
原始的SOA
把以往的单体服务中的某些模块拆分出来,每一个模块都是单体的功能,模块之间相互之间又相互有一些依赖,之间会有相互的调用。
这种架构用WebService就能实现,称作SOA,单指服务治理的模型。
以往微服务主要的技术栈指SpringCloud,Dubbo
原来,我们把单体服务按照业务线拆分为组件,
后来,我们根据功能把系统拆分为模块,比如日志监控系统、上传文件功能
但这些都不叫微服务
微服务
单体模块在进行架构设计的时候,是独立的存在,不依赖任何其他功能
微服务功能之间没有任何的依赖:不主动、不拒绝、不负责
- 不主动去推数据,而是等别人来取——不主动,避免一致性问题、脑裂问题
- 跨平台的,基于Http的Restful的远程调用——不拒绝任何远程调用
- 如果别的服务来调用我,能不能调通,是别人的事情——服务的容错、重试,全部责任倒置,由调用方来负责
关于RPC
Dubbo做远程服务调用的时候是基于RPC的,传输的是Java序列化对象,不能跨平台(跨语言)
DubboX使用 http 传输 JSON,替代RPC,可以跨平台(跨语言);XML也可以跨平台,但是效率更低
RMI:java本身提供了一种RPC框架
服务拆分和服务治理
服务拆分原则、方法论仅供参考,一定要自己多拆…
业务线的拆分
要对用量瓶颈进行拆分,比如磁盘读写、网络带宽的使用(生成头像、下载报表)、计算密集型…可以把它们拆开,主要目的是在资源的使用上互不影响。
对于2M以上的报表、疯狂刷磁盘的业务,可以拆分出来。
基于技术栈的拆分
将文件上传、搜索服务、通知/推送服务、邮件服务 拆分出来,供所有业务使用。
中台
前台:前端、接入层
后台:业务逻辑CRUD、数据库
中台,介于前台和后台之间,提供复用
可以分为技术中台、业务中台、数据中台
做中台的条件是之前的业务要有足够多,要有积累,才适合直接转化为多租户的服务
服务治理
微服务的运维成本远高於单体应用
亿级流量网关系统架构与设计
网关可以设置在整个系统的最外边(流量网关),也可以设置在系统内部(业务网关)
流量网关不能使用LVS,应该拥有识别功能(支持编写程序)AWF
可以使用Java(Tomcat、Netty),或Nginx+C+Lua
Tomcat 性能低,因为他要建立会话(上下文),不适合用来做网关
APR:异步网络传输
Nginx写的网关:用C/Lua写的
基于nginx的二次开发:用Lua语言写
可以nginx直接请求redis,返回html页面
https://tengine.taobao.org/
OpenResty