ITPub博客

一种支持海量复杂数据关系运算的数据库

中国在2015年发布制造强国战略第一个十年的行动纲领《中国制造2025》，这是中国部署全面推进实施制造强国的战略文件。

随着计算机、互联网技术的飞速发展，信息安全已然是一个全民关心的问题，也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全，如：物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。

对于微服务，每个人都有自己的理解，与互联网企业的大量落地相比，微服务在传统金融行业还没有普及，这首先是传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频繁；其次是技术能力约束了新技术的落地；再者传统金融行业对系统可用性和稳定性的要求非常高。

在传统的信息系统架构模式下，各个组织或各个部门根据各自的业务需求，在不同时期不同技术环境下建设出各自的信息系统。随着信息化建设的不断推进，业务活动呈现高频化、碎片化、场景化的特点。随之而来的是对系统的处理能力、容量、业务持续性、需求响应速度、运维响应速度的更高要求。

Spark是在借鉴了MapReduce之上发展而来的，继承了其分布式并行计算的优点并改进了MapReduce明显的缺陷。Spark主要包含了Spark Core、Spark SQL、Spark Streaming、MLLib和GraphX等组件。

本地读-本地写的多活数据存储架构是最难实现的数据模式之一。这一模式也常被称为“双活”或者“多主”，对于不同行业大容量低延迟的事务类应用而言，这是一种必备的能力。

分布式事务解决的问题很明确，就是在服务分布在不同进程、数据分布在不同数据库时，如何解决数据一致性问题。对于这个问题，业界的共识是不要启用数据库 XA 模式，因为分布式情况下，如果启用了 XA 事务，必然会有数据库锁存在，实际上造成了两个服务之间的耦合，与分布式服务的初衷背离，还不如部署在一起。在不使用 XA 的情况下，经常使用业务补偿和

最近经常在不同场合说，技术发展已经进入深水区。IT 技术发展已经越来越成熟了，尤其在金融行业，以前是解决从无到有的问题，现在该有的系统都有了，是解决进一步发展的问题。所谓深水区就是用原来单纯技术突破的方式不行了。例如有些企业，早年用流程系统解决了无纸化办公的问题，可下一个阶段做什么呢？

如果你在使用容器来构建应用的话，一定听过什么是“12要素原则”。“12要素”为开发微服务提供了一组明确的指引。人们相信只要遵循这些原则，就可以更容易的运行、扩展和部署应用与服务。

针对分布式架构下的数据一致性，大家也许会问这样的问题：跨系统间分布式事务如何解决？系统内多个服务的分布式事务如何解决？一个服务内多个数据源/数据库的分布式事务如何解决？……这些问题大家是很容易理解的，但是由于术语不准确，所以解释起来会有二义性，所以先要统一语言或者术语，也就是统一概念

现时的云原生应用由多种异构的服务或者微服务组成，服务间、服务与客户端之间的通信需要跨越浩繁的通信协议和拓扑结构。Ambassador就是部署在这样不断增长的异构的工作负载环境之下，也因此我们对于这种境况有着直接的认知。

微服务时下大红大紫。人们很容易迷失在决定使用“最先进的技术”这样的兴奋之中，把微服务这一行业“最佳”实践当作是本公司的正确选择，仅仅是因为有雪片一样的文章描绘了这一架构在Netflix这样的公司是如何的成功。

文章翻好后，我请一位在移动平台领域工作多年的同事看了下，他的看法是，首先文中所讲的一些内容并不适合中国的国情。比如，从他接触的客户来看，多数大厂的技术路线已经不考虑对基于WebView的应用整合。从UI模型的角度看，RN、Flutter（谷歌推出的移动框架，已经发布到1.2版本）包括国内一些业界的移动平台从未强调低代码，但是强调代码通过UI模型与设计尽可能连贯。

在不断强调缩减APP数量的今天，企业的APP内容越来越“内聚化”—— 一个APP已经不再是单个服务或者服务于单个业务线，而是成为多条业务线内容的集装箱。那在这单个APP内容不断扩充的背景下，如何做好消息的集中管理似乎也成为了一个不可忽视问题，本文就让我们一起来探讨这个问题。

各个细分行业和领域的组织机构正在持续的加速采用微服务架构。随之而来的是容器的使用以及端点和服务通信的爆炸式增长。企业内部的复杂性和不确定性正在不断增加。如何在这样的情况下实现对规模化通信安全性和可见性的管理颇具挑战。因此，无论是运营者或者开发者都强烈渴望将网络层的复杂性封装为一个新的网络基础架构层。当此之时，处理此事的最流行的方式是服务网格（Service Mesh）。

随着移动端对用户体验要求越来越友好，以及企业对代码能够跨平台执行的迫切需求。React-Native因此应运而生，从出生就一直备受关注。

对于机器学习的新用户而言，使用机器学习算法的一个主要的障碍就是算法的性能受许多的设计决策影响。随着深度学习的流行，工程师需要选择相应的神经网络架构，训练过程，正则化方法，超参数等等，所有的这些都对算法的性能有很大的影响。于是深度学习工程师也被戏称为调参工程师。

微服务日渐流行，几乎所有流行语言都提供了两种框架实现，一是面向Web开发的大型框架，一是面向小型应用的微框架。轻量级框架作为微服务架构来说，是个好的选择。微服务架构有很多优势，诸如高可维护性，独立部署等等。微服务架构让我们可以针对特定语言选择最优的解决方案来建立特定的服务，比如，针对爬虫类应用或者AI场景，我们可以选择建立一个Python服务；针对加密库的场景建立JS服务；针对Active Record的场景建立Ruby服务等等。基于这样的理念，我们不需要受限于使用单一语言来建立整个后端服务。

在本文中，可以看一下Ignite在处理其它数据源（比如关系数据库）的已有数据时，一个很有用的场景。通常在行业领域，很多系统还有着巨大的商业价值，它们必须得到维护甚至加强，未被开发的领域已经很少见了。而Ignite可以用于组织中的遗留系统或传统系统，以增加它们的价值并提供新的可能性，例如具有水平可扩展性的集群计算、显著的内存级性能优势以及使用机器和深度学习的新应用等等。