这是我的第一篇博客
那天翻到备忘录说是从18年入行以来就说当时要写博客记录自己的技术升级,但可惜这么多年了一直没写。最近失业找工作迷茫期,在外包呆了好几年,现在想跳出外包找一个有自己产品的公司有前景的,不好面,总结一下自己的经历,还有一些技术。
最近有一个项目是基于云原生的项目,做的是基于华为云的多租户的SAAS系统,公司提供平台,租户进入做各种定制化的业务。但是我对于这个云原生一直搞不清楚,以前部署是是物理机,虚拟机,然后上云,后来的云计算,云原生,对于这个展开学习。
云原生的定义
搜到的关于元原生的一些定义,主要体现在这几个方面:
-
容器化:将应用程序及其依赖项打包为独立、轻量级的容器,以提供环境隔离和可移植性。容器化技术(如Docker)使应用程序在不同的环境中运行一致且可靠。
-
动态管理:利用容器编排平台(如Kubernetes)动态地管理和调度容器化的应用程序。通过自动化管理,可以实现应用程序的高可用性、弹性伸缩和自我修复能力。
-
声明式 API:使用声明式 API(Application Programming Interface)描述应用程序的期望状态,而非逐步指定操作步骤。这样可以更好地实现自动化管理和可重复部署。
-
微服务架构:将应用程序拆分为小型、松耦合的服务单元,每个单元专注于特定的业务功能。微服务架构使开发团队能够独立开发、测试和扩展各个服务,并支持敏捷的开发和部署。
Google 还强调了云原生的价值观,包括持续交付、可观测性、安全性和团队合作等。
云原生的由来
我从最开始接触IT的时候做的是运维工程师,其实就是DevOps,那个时候我接触的就是一些物理机,然后需要去机房接触一些物理机,磁盘阵列,交换机等等这些物理机,我印象中想要给机子装系统那个时候需要拿着电脑去机房连接服务器的端口,还需要开关电源等操作,非常麻烦。后来就接触到云龙流水线,再后来就是云了,不需要对接各种虚拟机服务器了。后来就开始有项目上云了,但是上云以后,单体的服务需要改造成微服务,我们以前项目就是上云以后只是简单的部署了三个实例,然后通过轮询来调用各个接口。存在的问题就是以前的应用程序并没有很好的利用了云的特性,比如云的动态扩容,灰度发布等功能点没有很好的使用。我的理解就是采用云原生架构的应用就能自从开发阶段就是为了在云上部署开发运维的,所有能最大限度的利用云的特性,主要实现就是采用了微服务来架构,声明式API,容器化和动态管理K8s这些技术落地的,这就是云原生架构。
云原生的实现落地
我觉得云原生目前主要的技术一个是云化服务器的管理,还有就是springcloud全家桶,K8s和docker的部署+jenkins。目前我只有一个云服务器,资源也不是很充足。目前还没有具体的代码实现 待我稍后补充。
问题一:云原生和springcloud微服务的关系?
云原生和微服务是两个不同的概念,但是它们之间有一些重叠和相互关联的地方。
云原生是一种架构和开发方法论,旨在将应用程序构建、部署和管理在云环境中更高效、灵活和可扩展。它涵盖了容器化、自动化运维、声明式配置等多个方面的技术和实践,旨在提高系统的可靠性、可扩展性和可维护性。
微服务是一种软件架构风格,旨在将一个大型的、复杂的应用程序拆分成多个小型、独立的服务,每个服务通过轻量级通信机制相互协作,从而提高系统的灵活性、可维护性和可扩展性。每个服务都可以独立地开发、部署和扩展,可以使用不同的编程语言和框架,适用于大规模和复杂的应用程序。
虽然云原生和微服务是两个不同的概念,但云原生可以被视为一种微服务的实现方式,因为它使用容器化、自动化运维和声明式配置等技术手段来支持微服务架构。在云原生环境中,每个微服务可以打包成一个独立的、可移植的容器,并通过容器编排系统(如Kubernetes)来实现自动化的应用程序部署、水平扩展、故障恢复等操作。
因此,可以说云原生和微服务是相互关联的概念,云原生提供了一种更高效、更灵活、更可靠的微服务架构实现方式,而微服务则是云原生架构的一种核心组件。
分布式和微服务的区别
1.分布式架构更多的说是是将一个应用程序部署在多个机器上,注重于多个机器之间的协作;
微服务架构着重于将一个应用程序进行拆分成各种小的服务,注重于各个服务之间的协作
2。分布式之间通信使用的是mq或者http协议等进行通信;
微服务架构是rest或者rpc调用等进行通信
3.解决问题的方式。微服务架构更侧重于服务的拆分和独立部署,以提高系统的开发效率和运行效率。而分布式架构更侧重于不同物理机器之间的协作和共同工作,以提高系统的性能和可靠性。
4耦合度。微服务架构中的各个服务通常是解耦的,可以独立地运行和更新,而不影响其他服务。而分布式架构中的各个物理机器之间可能会有依赖关系,需要通过网络通信和接口进行数据交互,以保证系统的正常运行