随着dubbo,spring cloud在java世界的流行,微服务也成为当前架构的主流.简单的说,就是一个化整为零的过程.
- 后端微服务
微服务的本质就是拆分业务逻辑,把具体请求处理服务化,做到可复用,可扩展.这自然就多了怎么识别,管理这些服务的工作,也就是"服务治理".spring cloud还是提供比较完整的组件的.
SpringCloud简单架构图
- 前后端分离
这是微服务的第一个难点,原来的一体化结构,遵循的是请求->逻辑->展示.也就是传统的MVC模型,这些工作都在后端服务器完成,为了业务逻辑的一致性,自然服务器要跟踪每个请求的状态.
但是在微服务环境中,服务器是无法负责保存状态的(当然也有放redis这种折中的方法).业务的状态就变成要由前端(web浏览器)保存,后端只是做业务逻辑(Restful).
因此,前端react, angular, vue等就相继登场,催生了前端工程师的火热,不在只是切图,而是要负责整个客户端的状态管理,展示逻辑,运行逻辑.
前后端分离
3.数据库分库分表
业务逻辑微服务化了,如果都还是直连同一个数据库,只是把性能瓶颈下移了,还是无法进行自由伸缩.而数据库也要"微"化,必然需要对应的分库分表技术来配合,这个技术主要针对开源数据库,如mysql:
image.png
4.容器化和DevOps
现在前端,后端,数据库这传统三层架构都"微"化了,也就是说系统由一个大家伙,变成了一堆小朋友.如果每个都按原来的套路去.启动,停止,升级,那运维人员烦都烦死了.
Docker这样标准的"容器"正好符合统一管理的诉求,只要开发人员打包成可用的Docker Image,运维就不需要了解具体程序的启停逻辑(也就是屏蔽了技术细节,比如node用npm启动,java用java启动,数据库用sqld启动等等),用统一的docker运行命令搞定.
Docker解决了怎么用的问题,K8S出场解决怎么管的问题,通过Pod,Service,ReplicaSet,Deployment等概念,把对系统的运行看法程序员视角转换成了运维人员视角.当然这个也是有门槛的,DevOps应运而生.
DevOps
- DevOps辅助技术
这里就列个简单且不完整的表和一个参考的图:
Restful交互标准化: Swagger
服务统计度量: Metric, SOFALookout
CD/CI : Jenkins, Ansible
分布式链路追踪: Sleuth, Zipkin, Pinpoint，SkyWalking
统一代码质量管理: Sonar
日志收集: ELK
服务监控: Zabbix, Prometheus
参考架构图
通过1,2,3,4,5这么几步,软件世界就这么从一体化架构走向微服务架构,各个棘手的问题也都有解决方案.回过头一看,好像还有点问题,而且就在根子上.
- 后端微服务门槛高,需要了解服务治理的各个方便,
- 服务治理本身是代码级的(虽然spring cloud只是加个注解就行).
- 功能上和k8s有重叠,相当于同一个事情开发做一次,运维再做一次.(目前刚发布的spring-cloud-kubernetes项目,似乎能解决这个情况.)
要解决这几个问题的话......欢迎了解一下Service Mesh.
网友评论