「java微服务容器化」微服务容器化开发实战

本篇文章给大家谈谈java微服务容器化，以及微服务容器化开发实战对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、微服务：Java EE的拯救者还是掘墓人?
• 2、微服务架构之「 容器技术 」
• 3、运营商业务系统基于 KubeSphere 的容器化实践
• 4、java培训为什么这么火？java有什么优势
• 5、java课程分享常见的五种容器管理方法

微服务：Java EE的拯救者还是掘墓人?

引言

有人说，Java确实过于臃肿，经常“小题大做”。但PHP、Node.js扩展方面短板太明显，做小应用可以，大型应用就玩不转了。另外，JavaEE领域有太多优秀框架可以解决开发效率的问题，事实上借用Spring等框架，开发的效率丝毫不亚于PHP。

互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。

那么，微服务能完全弥补JavaEE的短板吗?对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色?

在Java问世之初，包括IBM、BEA、Oracle在内的一些巨头公司，看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢?答案就是，使用这门语言构建复杂无比的服务器，让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了JavaEE规范、JSR规范，以及WebLogic、WebSphere等服务器中间件。

在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。

因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。

RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。

在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。

2009年，RyanDahl启动了Node.js项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Node.js可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Node.js是一个很好的作品，但它也有自己的局限性。Node.js难以扩展，也难以与遗留的系统集成。

2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。

基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。

JavaEE厂商多年前，JavaEE厂商，比如Oracle和IBM，他们花费数亿美元开发应用服务器(WebLogic和WebSphere)，这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了，因为JBoss迅速抢占了市场份额，Oracle对JavaEE的支持正在走下坡路：

#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。

JavaEE客户

从客户角度来看，耗费巨资购买这些服务器是不值得的，因为JavaEE所承诺的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上，所以你需要花更多的钱去升级服务器，因为厂商可能不再支持旧版的服务器，而这样的更新会花费你数百万美元。

于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上?为什么我们要把应用打包成一个ear包或war包，而不是jar包?为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展?

微服务

微服务是这些问题的解药。Wikipedia把微服务定义为“??一种软件架构风格，复杂的应用由一些独立的进程组成，这些进程使用与语言无关的API进行交互。这些进程服务规模很小，高度离散，聚焦在一个很小的任务上，使用模块化方式来构建系统”。

微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。

微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。

如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。

不过从最近几年的发展情况来看，之前的方式有些落伍。操作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个操作系统一样。Docker运行在云端的操作系统上，而云端的操作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办?很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。

微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其他服务(开源或闭源的)集成，只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。EC2、S3及其他来自Amazon(或其他公司)的服务就是最好的例子。基础设施会成为应用程序的一部分，而且它们是可编程的。

使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。

随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：

#/dangers-microservices-washing-get-value-strip-away-hype

微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。

微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。

虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。

容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!

结论

应用开发的风格这几年一直在变化，而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用，这些小型应用被部署在云端的容器里。开源微服务框架LightJava为这些运行在容器里的微服务提供了很多特性，它支持设计驱动，开发者只需要把注意力专注在业务逻辑上，剩下的事情可以由框架和DevOps流程来处理。

那么问题来了，你怎么看?

微服务架构之「 容器技术 」

现在一聊到容器技术，大家就默认是指 Docker 了。但事实上，在 Docker 出现之前，PaaS社区早就有容器技术了，以 Cloud Foundry、OpenShift 为代表的就是当时的主流。

那为啥最终还是 Docker 火起来了呢？

因为传统的PaaS技术虽然也可以一键将本地应用部署到云上，并且也是采用隔离环境（容器）的形式去部署，但是其兼容性非常的不好。因为其主要原理就是将本地应用程序和启停脚本一同打包，然后上传到云服务器上，然后再在云服务器里通过脚本启动这个应用程序。

这样的做法，看起来很理想。但是在实际情况下，由于本地与云端的环境差异，导致上传到云端的应用经常各种报错、运行不起来，需要各种修改配置和参数来做兼容。甚至在项目迭代过程中不同的版本代码都需要重新去做适配，非常耗费精力。

然而 Docker 却通过一个小创新完美的解决了这个问题。在 Docker 的方案中，它不仅打包了本地应用程序，而且还将本地环境（操作系统的一部分）也打包了，组成一个叫做「 Docker镜像 」的文件包。所以这个「 Docker镜像 」就包含了应用运行所需的全部依赖，我们可以直接基于这个「 Docker镜像 」在本地进行开发与测试，完成之后，再直接将这个「 Docker镜像 」一键上传到云端运行即可。

Docker 实现了本地与云端的环境完全一致，做到了真正的一次开发随处运行。

一、容器到底是什么？

容器到底是什么呢？也许对于容器不太了解，但我们对虚拟机熟悉啊，那么我们就先来看一下容器与虚拟机的对比区别：

上图的左侧是虚拟机的原理，右侧是Docker容器的原理。

虚拟机是在宿主机上基于 Hypervisor 软件虚拟出一套操作系统所需的硬件设备，再在这些虚拟硬件上安装操作系统 Guest OS，然后不同的应用程序就可以运行在不同的 Guest OS 上，应用之间也就相互独立、资源隔离了，但是由于需要 Hypervisor 来创建虚拟机，且每个虚拟机里需要完整的运行一套操作系统 Guest OS，因此这个方式会带来很多额外资源的开销。

而 Docker容器 中却没有 Hypervisor 这一层，虽然它需要在宿主机中运行 Docker Engine，但它的原理却完全不同于 Hypervisor，它并没有虚拟出硬件设备，更没有独立部署全套的操作系统 Guest OS。

Docker容器没有那么复杂的实现原理，它其实就是一个普通进程而已，只不过它是一种经过特殊处理过的普通进程。

我们启动容器的时候（docker run …），Docker Engine 只不过是启动了一个进程，这个进程就运行着我们容器里的应用。但 Docker Engine 对这个进程做了一些特殊处理，通过这些特殊处理之后，这个进程所看到的外部环境就不再是宿主机的那个环境了（它看不到宿主机中的其它进程了，以为自己是当前操作系统唯一一个进程），并且 Docker Engine 还对这个进程所使用得资源进行了限制，防止它对宿主机资源的无限使用。

那 Docker Engine 具体是做了哪些特殊处理才有这么神奇的效果呢？

二、容器是如何做到资源隔离和限制的？

Docker容器对这个进程的隔离主要采用2个技术点：

弄清楚了这两个技术点对理解容器的原理非常重要，它们是容器技术的核心。

下面来详细解释一下：

三、容器的镜像是什么？

一个基础的容器镜像其实就是一个 rootfs，它包含操作系统的文件系统（文件和目录），但并不包含操作系统的内核。

rootfs 是在容器里根目录上挂载的一个全新的文件系统，此文件系统与宿主机的文件系统无关，是一个完全独立的，用于给容器进行提供环境的文件系统。

对于一个Docker容器而言，需要基于 pivot_root 指令，将容器内的系统根目录切换到rootfs上，这样，有了这个 rootfs，容器就能够为进程构建出一个完整的文件系统，且实现了与宿主机的环境隔离，也正是有了rootfs，才能实现基于容器的本地应用与云端应用运行环境的一致。

另外，为了方便镜像的复用，Docker 在镜像中引入了层（Layer）的概念，可以将不同的镜像一层一层的迭在一起。这样，如果我们要做一个新的镜像，就可以基于之前已经做好的某个镜像的基础上继续做。

如上图，这个例子中最底层是操作系统引导，往上一层就是基础镜像层（Linux的文件系统），再往上就是我们需要的各种应用镜像，Docker 会把这些镜像联合挂载在一个挂载点上，这些镜像层都是只读的。只有最上面的容器层是可读可写的。

这种分层的方案其实是基于 联合文件系统UnionFS（Union File System）的技术实现的。它可以将不同的目录全部挂载在同一个目录下。举个例子，假如有文件夹 test1 和 test2 ，这两个文件夹里面的文件 有相同的，也有不同的。然后我们可以采用联合挂载的方式，将这两个文件夹挂载到 test3 上，那么 test3 目录里就有了 test1 和 test2 的所有文件（相同的文件有去重，不同的文件都保留）。

这个原理应用在Docker镜像中，比如有2个同学，同学A已经做好了一个基于Linux的Java环境的镜像，同学S想搭建一个Java Web环境，那么他就不必再去做Java环境的镜像了，可以直接基于同学A的镜像在上面增加Tomcat后生成新镜像即可。

以上，就是对微服务架构之「 容器技术 」的一些思考。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。

运营商业务系统基于 KubeSphere 的容器化实践

大家好，我是宋磊，在运营商的一个 科技 子公司任职，主要做大数据业务。我主要负责公司的 IaaS 层和 PaaS 层的建设和运营的工作，涉及到两个层面。因为 Kubernetes 是一个非常全面的技术体系，并不是我们部署了一个集群把业务放上去就能开箱即用，涉及到很多方面，比如服务器、网络、存储，还有一系列的工具链的支持，我们才能真正的去投产，所以我们团队是比较适合做这件事的。

我们目前有三种类型的业务：1.接口的服务，容量占比是比较大的一块2.APP 的应用3.外部的应用系统，主要做智慧政务、智慧生态、智慧城市、智慧 旅游 等业务

这三个类型的业务，整体的 TPS 的峰值大约在 2500，平均在 1500 左右。

我们整体的集群规模：我们所有的集群都是以物理服务器进行部署的，生产集群有 50 个物理节点，测试的集群有 20——30 个节点，整体的 Kubernetes 集群的规模不到 100 个物理节点。

上面这张图是我们 Kubernetes 的实践。

IaaS 层：数据中心物理层的网络是 SDN 加 VXLAN 的架构，后续对于网络插件的选型是有考虑的。

存储这一块我们主要是对接 Ceph，我们有一个比较大的 Ceph 集群，大概有 50 个物理节点，其中对接层不单单跑了 KubeSphere 的这些业务，还跑了一些 OpenStack 的虚拟机。我们在 Ceph 上面做了一些数据的分层，闪存盘(存放集群元数据)和 SATA 盘(存放真正的数据)，也做了一些数据的热度分层，然后以 KubeSphere 为中心的容器集群周边做了很多对接的工具链。这其中的一些工具链不是容器化的，而是外链的，比如说 CMDB 配置管理，Prometheus 的监控，Skywalking 主要做微服务的全链路监控，还有一些日志的采集分析，主要还是以 ELK 的工具链为主，也是在 KubeSphere 集群之外的，DevOps 这层是基于 Jenkins 的 pipeline 去做的。

然后流量入口这一块，因为我们所有的业务类型都是互联网性质的，所以我们在互联网区域有一个整体的 Nginx 的集群，主要做业务的路由分发和流量的集中控制。

上文已经提到我们的物理网络已经是 SDN 加 VXLAN 的大二层的租户性质，所以对于 KubeSphere 的网络插件的选型，目前主要就两种——Calico 和 Flannel。

Flannel 本身就是基于 VXLAN的，如果选择它的话，相当于我们两个层面——物理网络和 Kubernetes 网络都是 VXLAN，这就涉及到两次层面的封包和解包的问题，对性能还是有一定的影响的，所以我们最终还是选择了 Calico 这种纯三层的 BGP 的网络，然后做网络的插件。

目前我们主要对接的是 Ceph 的块存储，服务于一些有状态的服务，比如我们会做一些 helm 的镜像，主要是 Zookeeper、Redis、MySQL。但是这些有状态的服务主要是在测试集群，给开发测试人员使用的。生产环境主要是一些无状态的服务，比如分布式框架的 Java微服务应用，还有 Python 和 go。go 主要是用来做区块链，因为现在区块链跟 K8s 结合是非常有必要的业务类型。

但是 RBD 块存储有局限性，我们很多业务需要多个 Pod 或者多个容器共同读写某一块存储，但块存储是实现不了的，后续我们还会有对象存储和网络存储（NFS）的对接。

CI/CD 这块，底层是 Jenkins，没有集成到 KubeSphere 里，因为我们之前有一个 Jenkins 的 Master 和 Slave 的架构的平台，基于 pipeline，镜像直接打到 Kubernetes 集群，做自动化的 CD。

日志采集相对来说会麻烦一点，目前对接的 ELK 的工具链，底层主要是采集三种类型的日志，宿主机日志、Pod 业务日志和 Kubernetes 组件相关的日志。宿主机和 Kubernetes 组件日志都是基于宿主机采集。

Pod 业务日志的采集，主要有两种方式：

ELK 的工具链是比较成熟的工具链了，可以参见上图。

我们是以两种形式来进行灰度发布。

我们对于服务治理这块后续可能会有一些需求，目前没有一种特别好的实践方式。

目前来说我们对于微服务治理都是基于辅助的手段，比如全链路监控，日志的指标，来做微服务的流量控制和垄断。后续我们想往服务网格上 探索 ，把流量的监测和控制放在平台层，开发只需要专注于业务的逻辑，目前还没有比较好的落地方案。

java培训为什么这么火？java有什么优势

经此一“疫”，越来越多的行业企业都将“数字化转型”作为未来业务发展的重要战略方向，随之而来的就是大量的技术变革。

作为一个Java编程开发的从业者，你了解Java编程语言在全球程序员中的地位吗？了解后微服务时代，也是就现在的云原生时代应该怎么做吗？

从上面的数据可以看出，java在微服务、云原生时代宏观上的困境已经出现，python、C语言已经把稳居榜首20多年的Java拉下神坛。

对此，下面就让我就详细分享一下 Java目前的困境和解决方案在哪里，让我们能够在大势所趋之下地位稳固！

Java目前的困境

一个事件：Java总体上是面向大规模、长时间的服务端应用而设计的。像即时编译器、性能制导优化、垃圾收集子系统等都是面向程序长时间运行设计的，需要一段时间来达到最佳性能

一个矛盾：在微服务、云原生的背景下，提倡服务围绕业务能力构建，不再需要再面对数十、数百GB乃至TB的内存；有了高可用的服务集群，也无须追求单个服务要7*24小时不可间断的运行，它们随时可以中断和更新。但在当下对应用的容器化亲和度（包容量、内存消耗等）、启动速度、达到最高性能的时间等方面提出了新的要求，这些又正好都是Java的弱项。

简单概述就是：Java是VM Base而不是Native Base的、Java的代码域是动态的、开放的而不是静态的、封闭的。

如何解决困境

在这里，我根据各大厂的高级开发工程师在面临上述困境时的解决方案，大致总结了以下四种方式：

革命派：直接革掉Java和Java生态的性命，创造新世界，譬如Golang

激进派：摒弃重负载的传统Java生态，在GraalVM上另起炉灶开发新的Java应用，譬如Quarkus,Micronaut

温和派：尽可能保留原有主流Java生态和技术资产，尽可能通过技术手段自动化地把遗留代码升级成为GraalVM Native应用。

保守派：在原有的Java生态上做改进，朝着微服务、云原生环境靠拢、适应，譬如CNCF Buildpack

注：GraalVM 是Oracle新一代的多用途（Universal）、多语言（Polyglot）的虚拟机，目的让Java脱离“虚拟机” 运行。

那拯救Java的技术生态到底在哪？

事实胜于雄辩，越来越多的从业者用实践已经证明Spring成为了java生态系统中的破局者。

java课程分享常见的五种容器管理方法

大家在开发应用软件的时候以及架构服务器的时候应该听过关于容器管理的一些方法吧。今天我们就给大家整合了一些比较好用的容器管理方式，一起来了解一下吧。

1.AWS弹性容器服务

AmazonECS支持Docker容器及其专有的Fargate技术。ECS是一个高度可扩展的平台，允许用户安装和运行自己的容器编排软件、管理和扩展虚拟机集群，或在这些虚拟机上安排容器。

这包括长期运行的应用程序、微服务、批处理作业和机器学习应用程序。AWS容器产品与许多其他AWS服务集成，包括弹性负载平衡、AmazonVPC、AWSIAM、，AmazonECR、AWSBatch、AmazonCloudWatch、AWSCloudFormation、AWSCodeStar和AWSCloudTrail。AWS还为Kubernetes(EKS)提供弹性容器服务。

亚马逊网络服务是云计算基础设施市场份额的行业领导者。它在公共云中拥有41.5%的应用程序工作负载。这使其成为组织的焦点，其中包括任何考虑容器的公司。

2.AzureKubernetes服务(AKS)

AzureKubernetesService(AKS)提供了一个功能强大的托管工具，用于使用和编排容器，以及动态扩展基础设施和应用程序。AKS使用Azure门户和AzureCLI或Azure资源管理器和Terraform等基础设施代码工具来配置集群。

AKS提供了几个关键功能：控制平面遥测、日志聚合和容器运行状况可见性，作为Azure门户的一部分。它还具有自动升级、修补和自我修复功能。

凭借基于应用程序工作负载的近30%的市场份额，微软Azure也是企业云计划的核心。更重要的是，它的市场份额正在增长。该服务旨在通过引入高度自动化的流程来简化DevOps，这与流程管理相辅相成。

3.DiamantiD10

Diamanti的D10裸机容器平台提供统一的解决方案，java课程建议可以大规模托管和运行容器化应用程序。它插入现有的VLAN和DNS基础设施。

关于java微服务容器化和微服务容器化开发实战的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。