| June 12, 2018
从单体到微服务，论企业级应用服务器到微服务基础设施架构设计演进
本文原文发布在InfoQ中国微信公众号上。 链接
一，架构问题：
作为一名软件工程师或者系统架构师，当我们在构造大型应用系统时，常常需要画出一个体系架构图，来表现要开发的应用系统的软件架构。 我想很多软件开发人员都有这样的疑问：这几年业界都在谈微服务，容器化，这样的技术变化的原因是什么？新的或者原有的软件系统到底该用什么样的技术架构体系？如果需要改造，应该怎么做？ 希望通过阅读本文给您一些启发。
二，技术背景：
应用服务器是近十几年来应用开发的主流部署环境。以Java语言社区为例，Java EE 应用服务器是软件中间件开发领域的主要产品，包括以Weblogic, Websphere商业产品， JBoss AS(Wildfly), Glassfish开源产品，还有Tomcat, Jetty等Servlet容器服务器，Spring Framework应用框架等，这些共同组成商业业务软件最重要的部分。
容器Docker，容器编排Kubernetes等带来了容器化微服务软件技术浪潮，互联网公司作为先行者，并在国内外引领软件设计的方法变革，Cloud Native已经成为当前软件设计中必须考虑的要素。
那么，“传统”的应用服务器和Kubernetes之间是否有技术关联性？如果有，它们的内在联系是什么？
三，相似之处：
我在专业技术网站找到了两幅图片，分别是完整的JavaEE实现Wildfly应用服务器域模式和kubernetes架构体系图。
图片来源于 https://kb.novaordis.com/index.php/WildFly_Domain_Mode_Concepts
图片来源于 https://x-team.com/blog/introduction-kubernetes-architecture/
以上两幅图，并不是这两个产品所有技术架构细节最全面的图形，但已经能够充分表现它们的架构特点和组件之间的关系。
我们发现，两者的架构有很多一致的地方：
- 都有一个主控节点，Kubernetes称为Master Node，Wildfly中是含有domain controller的host1，也是作为主控节点。
- 通过主控节点管理多个工作节点，Kubernetes有两个Worker Node，Wildfly图中也有两个工作节点host2和host3。
- 管理员通过管理接口(Rest API)来对整个系统进行管理，Kubernetes是通过kubectl访问API server，Wildfly是通过jboss-cli工具访问管理接口，服务器处理组件是domain controller。当然，它们也都提供图形管理工具。
- 工作节点上都有控制进程，Kubernetes是kubelet和kube-proxy，Wildfly为host controller和process controller，其中kubelet和host controller作用类似，都是起到工作节点和主控节点通信和管理节点工作进程的作用。
- 每个工作节点上都有多个工作进程，只不过Kubernetes是由容器管理Pod，而Wildfly是JVM进程管理工作线程。
另外图示中没有表示出来，或者在逻辑上概念相似的还有：
- Kubenetes中的controller-manager包括各类功能的控制器模块，Wildlfy中有类似的功能组件，也在domain controller中，它们都具备可扩展能力。
- Rest API对外接口采用简单易懂的Json格式，各个节点间为了高效率，通信方式为二进制数据流，都可以配置加密方法。
- 尽管工作进程中，Pod和线程有所不同，但逻辑上也有相似之处：都是独立的工作主体，都有完整的生命周期；Pod间共享网络，存储等信息，线程间可以传递上下文。我个人更愿意把Pod看作是隔离性更好的“工作线程池”。
- 不同的节点或者进程中的服务工作单元，可以动态的组成服务群组。Wildfly中有Server Group概念，一个应用可以被同时部署到Server Group的所有工作单元；Kubernetes的Pod可以通过定义的Label来Selector，即可以筛选出具有某些标记的Pod，而作为服务群组对外提供服务。
- Kubernetes有Service来提供服务，这样对于服务消费者，后面Pod服务提供者的信息都是透明的。而且还有Ingress对外部应用进一步暴露服务能力。Wildfly提供了Wildfly-cluster作为服务组件的反向代理。虽然做不到像Service那样直接通过iptables底层机制去映射网络访问端口，但同样也有强大的根据负载能力调节转发请求量的特性，更多的是Ingress的作用。
- Kubernetes对有状态的组件支持，是通过StatefulSet，挂接Persistent Volumes，重新构建相同状态的工作容器。而Wildfly中对状态的管理，包含Stateful SessionBean, Servlet session等，都是通过Infinispan的分布式机制，复制状态到多个节点，而且还有一种远程Infinispan的配置方式，就和Kubernates对状态的管理逻辑上完全一致了。
- 对于Master主控节点的安全性管理，两者都有完备RBAC用户管理认证授权机制，以及完备的加密方式，密钥配置管理等功能。
Java EE技术一直是一个完整的开发生态，同样的，Kubernetes也快速的形成了庞大得多的生态体系，我们从其中一些对开发很重要的方面进行分析。
- JavaEE有一套标准的打包方式，如构建jar，组合成应用war，进而打包成企业完整应用ear。Kubernetes是利用容器镜像，即docker的打包机制来管理容器。在docker之上，Kubernetes提出Pod概念，对于整体的应用部署，目前Kubernetes社区提供了helm工具和chart包格式。当然也类似yum工具管理的rpm格式等。
- Kubernetes动态扩容，即ReplicaSets定义的创建特定数目的实例，可以说是Kubernetes最重要的特性之一。JavaEE定义的Stateless SessionBean，在应用服务器实现中，会创建一个池来实例化多个，虽然实例个数控制粒度没有那么细，但也是可以通过控制台来定义其实例数量的，实例池由容器来保证其可用实例数目。
- Kubernetes用ConfigMap来定义配置信息，用Secrets来定义安全方面的配置信息。JavaEE也有类似的定义，比如Resource和Securtiy方面的annotation。在应用服务器扩展方面，Wildfly可以自行定义xml schema，提供友好可读的xml配置信息，以及Security Domain/Realm来定义安全方面的配置信息。
- 原Coreos（后被红帽收购）定义的Operator Framework（运维框架），基于Kubernetes CRD（Custom Resource Definitions），定义了完整的一套打包，部署，管理应用的方法，有了这样的工具，第三方软件产品，可以用一种相对“标准”的方式提供容器化的产品。Custom Resource Definitions是Kubernetes的扩展机制，可以预见Kubernetes三方扩展将会如雨后春笋般的出现。对应的，Wildfly有子系统（subsystem扩展机制），可以在Wildfly服务器内核之上，开发子系统来扩展功能，Wildfly所有的Java EE都是通过子系统方式实现的。它们都是通过扩展Controller的功能，把管理命令挂接到API server之上，设计思路惊人的一致！
- Wildfly工作节点的管理，可以通过暴露信息发给主控节点，也可以利用JMX，Java agent，Interceper等方式来发送数据到分布式数据中心上（比如可以加载jolokia），再用独立的或者统一的控制台来管理。同样的，Istio项目，也是利用sidecar模式，在pod工作进程上，挂接一个envoy模块，由其完成流量分配，安全管理，policy设置等功能，再由控制台统一管理。
- Kubernetes被成为容器编排产品，所谓编排(orchestration)，就是把不同的应用运行组件，按照实现定义好的规则，根据其依赖性能够启动运行，并保证其运行健壮的能力。Java EE各个规范间也有依赖性，比如Webservice依赖于Servlet，Wildfly有一个组件成为DeploymentFramework，也是处理组件之间的依赖关系的，服务器会按照应用定义好的最终状态声明，按照自己的依赖性原则，逐个启动各个服务，保证应用最后可用。
四，异同之处：
毕竟Kubernetes是演进后技术，具有大量新的特性：
- 存储方面的特性，Kubernetes可以挂载各种存储，包括普通的文件系统，NFS，云端的S3，开源存储方案Ceph等应有尽有。Wildfly还是使用标准的操作系统的文件和目录。利用容器，Kubernetes能更方便的对文件限额，资源使用量等进行定义和限制操作。
- 网络方面的特性，Wildfly定义了网络接口配置属性，可以对网络IP，端口，偏移值等进行设置。但这些比起Kubernetes来说就是九牛一毛，Kubernetes在Service层，就利用iptables等方法做网络请求的路由映射，而且商业Kubernetes产品都会加入SDN（软件定义网络）的方案，网络管理成为应用体系重要的一部分。
- Kubernetes中非常重要的组件是scheduler调度器，这个在Wildfly中没有功能完全一致的组件，因为企业应用的集群部署是按组整体部署的，Wildfly提供了控制台工具来部署到不同的节点上。尽管这个过程可以自动化，甚至可以引入一些智能的成分来“调度”，但还是和kubernetes提供的调度能力相差甚远。
- 对工作节点的管理的规模不同。企业应用服务器集群一般在数十台左右，和互联网动则成千上万的服务器差了几个数量级。对事务的一致性要求也是不同的，它们对于状态信息的分布式分发复制方式存在差别。
- 企业级应用服务器，应用上下文信息包含了事务，安全等信息，在线程间进行传递。而应用分布后，微服务之间也要传递安全，事务等信息，就要用OIDC/Jwt，TCC/Saga等分布式方案，业务目标是一致，但实现方法变化很大，也对软件架构设计提出了很高的要求。
五，总结和展望：
毫无疑问Kubernetes已经赢得了容器之战，甚至取代docker成为容器技术中最重要的开源产品。开发工程师和架构师也需要适应微服务化技术的演变，部署应用到云端，这个趋势已经开始。
同样的，Kubernetes和生态，对于应用开发和运维也提出更高的要求。企业在开发软件应用时，也要多方位考虑，包括应用复杂度，访问量，事务的要求，运维能力等。选择最适合技术和中间件产品/云计算平台。软件设计没有银弹，最适合的才是最好的。