大魏的思考：从纯技术角度看数字化转型
大魏的思考：从纯技术角度看数字化转型
前言
本文仅代表作者个人观点，本文在书写过程中，得到了红帽技术专家蔡书的指导，在此表示感谢！
一、数字化转型
当下IT界，IT公司都在谈帮助客户实现“数字化转型”、“业务转型”。在此，我不做评判。但从技术角度看，真正做应用的公司，才能比较容易地帮客户实现数字化转型。
本质上讲，当前的“数字化转型”、“互联网+”，更多指的是前端类应用，因为这类应用的转型，可以直接提升客户的体验，从而塑造企业的竞争力。
举个例子，最新的ios11.3目前已经支持公交卡了。这解决了最终客户的我的三个问题：
1.以前公交卡总丢，造成经济损失
2.为了预防公交卡丢的问题，我将公交卡和RedHat工卡放来了一起；这样一来增加了重量，二来看起来很不拉风。
3.公交卡充值更方便，无需再排队。
新一代的应用，需要新一代的基础架构与之对应；这就像生产力和生产关系之间的关系。
所以，对于手机类、互联网类应用，显然容器更为合适。
根据Gartner的定义，容器可以做四类事：
1.PaaS
2.Devops
3.微服务
4.HPC
在这四项里，HPC我接触的案例不多。就前三个而言，PaaS实现最容易事先，他主要面向运维；Devops稍微难一些，它涉及开发和运维；微服务最难，它牵扯到了应用和业务逻辑。
接下来，我们从就应用和PaaS、微服务、Devops这三方面的关系，谈谈我对企业数字化转型这个话题的看法。
二、单例应用的集群化
传统的Java应用设计模式是“单例应用”----Singleton。通常这种应用，整个应用只有一个共享的实例，这个实例访问一个对象。
（下图源自：http://terrylee.cnblogs.com/archive/2005/12/09/293509.html）
Singleton的应用有很多，比如windows中打印机。我们在电脑上打开打印机以后，再度点击打印机的运行图标，不会打开新的窗口。windows里“我的电脑”、“回收站”也是这样。
Http的应用，也是典型的Singleton应用。如果需要将Singleton应用配置成集群提高性能并消除单点故障，怎么做呢？有两种方法，它们的差别在于配置细节，以及需要对应用打包和源代码进行的更改。
1.Singleton deployment 单例部署（类似EAP5）
如果应用软件包中包含专有的部署描述符 /META-INF/singleton-deployment.xml，则它被视为单例部署。
2. Singleton Service 单例服务（类似EAP6）
这两种模式都允许Singleton应用在EAP集群中以主备方式运行。
单例服务按照与内部 EAP 服务相同的方式实施，即：它们的源代码使用 WildFly 核心 API，优势：
- 选择策略可由应用定义，无需配置 singleton 子系统。
- 它允许 EAP 模块启动群集范围的单例服务，这与 EAP 4 中旧版的 JBossMQ 类似。也就是说，它允许 EAP 充当主动-被动集群服务。
Singleton deployment和Singleton Service模式都由Singleton子系统的infinispan cache实现。而运行Singleton应用的EAP server实例，我们管它叫这个应用的server master。
在EAP7中，Singleton的master选举有两种模式：
1.Simple：第一个加入集群的节点运行Singleton应用。
2.random：集群中的随机选择一个节点运行Singleton应用。
模式的模式是simple：
如果Master出现故障，则 singleton 子系统会为将故障服务器用作主服务器的所有单例应用运行新的选择。
接下来，我们看一下如何通过EAP7实现Singleton的高可用。
启动第一个EAP实例：
启动第二个EAP实例，我们看到两个实例绑定的public和privateIP是相同的，但端口偏移量不同：
接下来，登录EAP集群的控制台，部署一个集群应用：
到这里，细心的读者可能会问，集群应用是否需要在war包中的应用做设置，答案是肯定的。在应用的web.xml中需要包含如下字段：
这样，集群应用被部署到了两个EAP实例上。这个应用内含一个访问计数器。
我们先访问第一个EAP实例上的应用，提示访问次数为1次：
再访问第二个EAP实例上的应用，提示访问次数为2次：
这就说明，两个实例的数据是通过infinispan cache实现了session的同步。
上面的实验，访问两个实例是不同的端口号（端口偏移量）实现，真正生产上不可能这样做，需要配置负载均衡器。
三、为单例应用集群配置负载均衡
传统的web负载均衡需要静态配置。每个后端web server的连接需要手工配置大负载均衡器上，负载均衡器检测后端web server的健康状态；而增加后端的web server需要修改负载均衡器的配置文件并重启。
而EAP7的mod_cluser模块可以动态构建后端web server列表，检测到新加入、新部署的web server。如果一个web server出现故障，负载均衡器不用修改配置文件。我们可以称这种为动态负载均衡。
接下来，我们通过实验展示为web server配置动态负载均衡器。
部署一个新的EAP，配置负载均衡，增加第一个server的IP和端口号：
增加第二个server的IP和端口号：
都添加成功以后，再度访问应用，URL输入的是负载均衡器的IP和8080端口。
第一个访问（默认启用session affinity）：
刷新页面：
四、PaaS
"有时会有一种观点认为， Singleton 模式在Java code中是一个反模式。"
为啥这么说，其实也不难理解。
“单例应用需要创建类，而与其创造这个类，你还不如通过注入来实现”
我们在上文中提到，Http的应用，也是典型的Singleton应用。在PaaS平台（基于容器的）出现之前，这类sigleton类的应用，需要借助于向EAP Domain模式来实现集群统一管理（Domain是EAP的管理模式而非功能模式），或者通过EAP的standalone模式配置集群来实现应用的集群（上文中的实验是通过standlone来实现集群的）。
而在Openshift等PaaS平台出现以后，Openshift希望每一个执行单元都是相对独立的。
在这种情况下，针对于Singleton应用：如果应用本身是无状态的，可以不用集群模式，通过Openshift的rc来保证EAP pod的高可用（例如session放在外部存储上）；如果session需要在内存里做同步，则需要配置EAP集群。
红帽官网提供EAP的容器镜像：
此外，运行在PaaS平台的应用，大多是无状态的应用，如果对稳定性和可靠性要求不是很高的情况下（相对于EAP而言，EAP的代码质量很高），也可以使用红帽容器镜像仓库提供的tomcat和widfly。
所以说，Openshift等PaaS平台的出现，使中间件的选择和使用更加灵活。
我这里分享一个使用Openshift前后，对应用的提升（客户名称不方便透露）：
五、再谈微服务
关于微服务的实现，Dubbo、Spring Cloud等都比较出名。这两个架构，我和我的同事在项目中也都遇到过。
关于Spring Cloud，我做过一些实验验证，具体实现这里不再赘述，参照：
从技术角度看，使用Spring Cloud实现微服务，架构比较复杂，而且很多应用的相互调用关系都需要写在代码中，这样应用变更也很不方便。所以，目前看到的客户落地的微服务架构，通常采用Spring Cloud的某几个组件，整体全部采用的并不多。
我一直相信, 当一个事物的完备性大于它的实用性和敏捷，距离尽头也就不远了。这点在IT技术上更适合。所以，在微服务层面，我比较看好Istio，与Spring Cloud相比，它具有架构性和代次的优势。
Istio是新一代微服务架构，这个观点我在去年的文章中已经介绍过了。今天我们看一下这种架构的优势。这个架构的核心观点，就是提供一种：尽量减少开发人员处理其应用程序分布式特性的要求的微服务架构。
Istio的架构图如下：
Istio分为数据平面和控制平面。
Istio的管理平面有三个核心组件：
Pilot：负责流量管理发现
Mixer负责：访问控制、策略管理、信息收集
Auth:负责认证
Istio的数据平面创建了一个跨平台的服务网格来解决常见的微服务架构问题，如其中包括很多：通信，负载平衡，流量路由，指标，配额，身份验证，速率限制，断路器，超时，自动重试，等等。Istio的数据平面采取sidecars的方式，也就是在一个pod的主容器旁边，增加一个istio的proxy。
关于Istio的实验已经验证，我在之前的文章已经写过很多了，这里不再过多赘述。
所以说，微服务的实现，本人更看好Istio，也很期待它在Openshift上的正式GA（目前是技术预览）。
六、Devops
这两年，我们都在提devops。其实对于传统的应用，想直接实现devops是有难度的，需要做一定的应用改造。对于传统应用改造，最基础的是应用容器化。
从技术侧，有三种方法可以实现。三种方法我都用过，各有各的好处。从效率角度，第三种最高。
三种方法具体的实现逻辑，我之前的文章有具体的代码和实现步骤，这里不再赘述。
而对于新的云原生应用，实现devops就容易的多。
下面我们对比一下传统应用和云应用：
目前有关devops的课程和方法论很多，这里不再赘述。但对于IT技术人员，如果只谈方法论而不谈工具，那显然是不合适的。
实际上，devops先于docker和K8S出现，但docker和K8S使devops更具备技术上的可操作性和灵活性。目前的主流IT公司，帮助客户实现应用devops，大致采用如下整体工具链。
上图是一个比较典型的Devops流程。包括产品立项、需求分析、应用设计、开发、测试、持续发布、生产运维、回顾阶段。
如果将上面的流程进一步工具化：
如果再技术细节一点，从我的角度，就是Openshift与Jenkins的集成了。这里我就不再赘述，详细内容参照以前的文章，里面介绍了两者相互配合的实现方式。
我这里再分享一个使用Openshift前后，对应用的提升（客户名称不方便透露）：
总结
企业数字化转型是必须的，这已经不仅仅是锦上添花的了，而是事关企业生死攸关的问题。当然，企业数字化转型，并不是只有红帽一家IT公司才能做这件事。但是，我看到的趋势是，当下的企业数字化转型，绝大多数是借助于开源的相关技术，而本质上这些技术都是来源于开源社区。
魏新宇
"大魏分享"运营者、红帽资深解决方案架构师
专注开源云计算、容器及自动化运维在金融行业的推广
拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、ITIL V3、Cobit5、C-STAR、AIX、HPUX等相关认证。
参考文献：
1.https://blog.csdn.net/u013256816/article/details/50427061
2.http://www.voidcn.com/article/p-zqpzpeos-bau.html
3.https://blog.csdn.net/Mr_PH/article/details/77898243
4.https://blog.csdn.net/u013256816/article/details/50427061
5.红帽实验手册