最近在读了《持续演进的Cloud Native-云原生架构下微服务最佳实践》这本书,大致内容是介绍了在云原生架构下无服务的最佳实践方式,书中详细介绍了架构的演进历史、云原生架构下微服务的架构设计原则,包括敏捷基础设施及公共基础服务、可用性、扩展性、一致性的设计,并且还探讨了未来值得关注的方向。
总的来说,相当于是给云原生下微服务框架的发展提供了一个相对成熟的指导方向,但是,大家知道,所有的武功秘籍都是死的,只有使用他的人将武功秘籍结合自身的实际情况进行融会贯通,才能将其效果发挥到最大。做软件也是一样的,在实际的开发过程中,结合实际的需求、团队的规模、以及团队中各类人员的技术水平。在架构和技术选型的时候,以最小的代价做出符合客户需求的软件功能,这才是最佳实践。所以系统要不要上云、要不要拆分微服务,如果要拆分的话,拆分的粒度怎么把握,这些都是团队的领导者或者是架构的设计者需要仔细考虑的问题。
作为开发人员的我们需要做的就是不断完善自己的技术栈,有人说做后端就专门研究后端的技术,不用考虑前端的知识,做前端就专门研究前端的技术,不用懂后端的知识,事实真的是这样吗?也许在大厂,的确是这样的,每个人只用负责自己所在的模块,前端和后端的交互靠接口文档就能搞定。如果有机会,每个人都愿意去大厂去做一个螺丝钉。大厂有大厂的优势,但是缺点也很明显,如果自己自制力不是很强,又没有自动自发地去研究工作以外的技术和知识的话,那种岗位和工厂中流水线的员工有什么区别,每天做着重复的CURD、接口调用,被外人戏称为CURD工程师和接口调用工程师。
然而有很大一部分人是进入不了大厂的,很多都进入了中小型的公司,这些公司的职位分工就没有那么明确了,很多现在用的架构也都没有前后端分离,况且现在技术发展的很快,未来开发和运维的边界也越来越模糊,DevOps、CICD、敏捷开发的概念被越来越多的公司推崇、自己想想只会一种单一的语言和技术还能满足市场的需要吗?况且在云原生的环境下,JAVA、C#、C这些语言开发出的项目显得越来越臃肿,很多公司都已经转向更轻量级的语言Go,去完全拥抱云原生了。
最近大环境不好,互联网的红利期已经没有前几年那么火热了,每个人考虑好自己接下来需要怎么发展,还没有入行的考虑好要不要真的入行软件开发,已经入行的考虑好以后自己的知识储备能否在市场上混的游刃有余。最后希望每个人都能够在事业上蒸蒸日上,生活上一帆风顺。