hero

江文|Full-Stack Developer

全栈开发|DDD|Cloud Native|Service Mesh

Istio从入门到入土 →

无所不能的大后端

后端开发也称为服务器端开发,是创建可运行的Web应用服务端程序的过程,通过使用Java、golang等语言并通过相关的技术、框架和库来实现具体的业务逻辑并使Web应用正常工作。随着互联网与云计算技术的发展,Web应用架构经历了从单体应用到微服务的巨变,功能越来越强大、复杂,与云的契合度也越来越高,迭代速度越来越快,对后端开发人员的考验也越来越严峻。

Cloud Native 势不可挡

云原生(Cloud Native)并不是一种具体的技术,而与微服务一样,是一组概念的集合,包括:DevOps、持续交付、微服务、敏捷基础设施、康威定律等。云原生既包含技术,也包含管理,还涉及流程。Cloud Native也可以说是一系列云技术、企业管理方法的集合。实际上,Cloud Native现在还仅仅是个概念,或者说是思想,一千个人眼中有一千种Cloud Native。

Service Mesh 解决复杂问题

Service Mesh彻底把服务治理逻辑从业务代码中剥离出来,成为了独立的进程(Sidecar)。部署时两者部署在一起,业务代码完全感知不到Sidecar的存在。这就实现了治理逻辑对业务代码的零侵入——实际上不仅是代码没有侵入,在运行时两者也没有任何的耦合。这使得在整个微服务架构体系中不同的微服务完全可以使用不同语言、不同技术栈来开发,也不用在业务代码中解决服务治理问题。

Go——云原生时代的C语言

Go语言是一种编译型的强类型、静态类型语言,且性能强大——在语言层面支持并发,拥有真正的协程goroutine,还支持GC。Go语言简单易学,拥有很多语法糖,语法简单、严谨,轻量易用,部署方便。由于很多Cloud Native产品都是使用Go语言开发的——如Docker、K8s、TiDB等,再加上Go语言高性能、语法层面支持并发等特征,所以Go语言堪称“云原生时代的C语言”。

DDD 将成为 CRUD 的出路

领域驱动设计(Domain-Driven Design,DDD)打破了系统分析与设计的隔阂,是用来设计和实现业务逻辑的一剂良药。虽然DDD不能解决一切问题——面向数据库的设计在简单的系统上会更好用,但它在上亿流量的大型微服务项目和快速迭代的小项目上都有良好的表现。或许在不远的将来,面对越来越复杂的系统、越来越深入和丰富的用户需求时,DDD将成为我等CRUD工程师的出路。

学会思想,而不是学会框架

我们在学习时很容易陷入只学习如何使用语言和框架而不学习其设计思想和基础知识的误区。其实,我们学习框架不仅仅是为了学习如何使用它们简化我们的开发工作,更要学习这些框架的本质和好的设计思想——如Spring Data JPA隐藏Repository层的细节其实是为DDD服务、Spring AOP是动态代理的绝佳实现等。学习框架时,最不应该忽视的便是基础概念和设计思想。

# 关于我

不想当切图仔的crud仔不是好架构师。

22届本科毕业生。一个整天研究后端的假全栈。

现就读于山东科技大学计算机学院计算机科学与技术专业,但我还是比较喜欢软件工程。

后端开发爱好者,DDD、CQRS/ES的支持者、践行者,微服务、Cloud Native、Service Mesh爱好者,希望能为Cloud Native、Service Mesh、DDD、CQRS/ES等社区做出贡献。

可以搞前端,但是没必要。React、Umi、Ant Design用户。

喜欢底层的框架和基础设施,也喜欢上层的应用和业务逻辑。

Gopher。写过Java。对Kotlin稍有了解。会一点JavaScript。

考研中,小事勿扰。

感谢你这么厉害还来看我的文章。希望能结识更多后端开发、Go语言、DDD、Cloud Native、Service Mesh方向的大佬,和大佬们共同学习、共同进步。

# 兴趣爱好

  • 后端开发/Back-end Develop
  • 重构/Refactoring
  • 微服务/Microservice
  • 云原生/Cloud Native
  • 服务网格/Service Mesh
  • 软件架构/Software Architecture
  • 领域驱动设计/Domain-Driven Design, DDD
  • 命令查询职责分离/Command Query Responsibility Segregation, CQRS

# 为什么要考研?

鉴于这个问题我最近被问了很多次,并且认识我的同学们一听说我要考研都觉得有点不可思议——我们专业去年刚刚有一个学姐去了宇宙厂,还拿了40k,而我能力比她强很多,不选择就业好像有点不可思议。为了不再花大力气去解释这些事情,所以就在这里统一解答一下。

是的,我的能力和项目经验或许已经可以支撑我找一份很棒的工作,但是我还是决定考研。

至于原因,只有一句话:世界那么大,我想去看看

另外,只有考研上岸了,我才能有充足的时间去研究我喜欢的架构、领域驱动设计、Cloud Native、Service Mesh、高并发、高可用,也会有更多的时间来重新学习我所不擅长的前端,并且也不会因为这些研究方向与学院里主推的研究方向不合而被认为是个loser。我在有就业能力的前提下没有选择就业,并不是排斥就业这个选择。相反,我非常想去大厂做架构、高并发、分布式和微服务相关的工作,也想在实际运行的应用中推动DDD和CQRS/ES的落地,更想做出可运行可上线的大型微服务项目,但我更倾向于将自己喜欢的这些东西全面了解后,再去就业

所以,虽然考研的过程没有写代码、读书、写技术文章那么快乐,但是为了以后能有更多的时间去做这些事情,我还是要考研的,并且一定要考上。

# 友情链接

友情链接的排序按照友情链接的添加顺序,欢迎交换友链。

# 联系方式

QQ由于垃圾消息太多又不方便屏蔽而长期开启请勿打扰状态导致回复消息不及时,如果有什么想交流的建议通过微信、邮箱或者tg进行联系。

提问前请阅读《提问的智慧》 确保充分理解文中内容再进行提问。考研时间紧任务重,我会无脑拉黑任何不经思考就发无意义的消息或群发没用的消息的人,敬请理解。