java 微服务技术架构图,Java架构下的微服务之路

随着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.