BI产品应用微服务架构的可能性探究

　　作者：邓天佐

　　“微服务”是近年来（2014年起）逐步兴起的软件架构概念，有趣的是，虽然很多的软件都在谈“微服务”，但其并没有一个统一且官方的定义和指导手册。

　　简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务开发者仅仅需要做最低限度的集中管理。

　　传统的企业系统都分为三大部分：客户端用户界面，数据库和服务端应用系统。这种单块（monolithic）的架构风格使得系统的任何改变，都会要实现以上三大模块的版本迭代，且需要充分考虑三者之间的融合性。这使得单块应用很难通过迭代成为一个越来越好的模块化结构，因为这样的开发方式无法将一个模块的变更控制在该模块内，使得迭代的风险性和占用的资源变得难以控制。这也让微服务架构在越来越多地出现在新兴系统架构理念中。

　　其实容易预见，随着各种系统的微服务架构风格的普及，BI系统作为各种业务系统的辅助系统，必然也会跟随这股潮流，进而适应越发复杂的场景。BI的微服务架构会有哪些值得期待的特点呢，具体来说有如下三点：

　　1.BI功能应用超市式开发。微服务架构的特点决定了它的核心逻辑是将复杂性问题分解，虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，这样使得微服务开发的速度要快很多，更容易理解和维护。具体的表现就是用户能从BI工具中以自由度更高地方式加入或剔除功能，超市般的选择模式，进而适应自己的业务场景。而随着功能越来越多地实现打包，BI开发的门槛也将越来越低，这十分符合近年来业务方直接使用BI进行分析的趋势。

　　2.BI部署实现“零件组装式”。上一个特点是从用户使用层面说的，而这个则是从供应商和客户选型上而言。在用户选择各类BI产品的时候，过去或许局限于某个产品或品牌，但是未来极有可能出现集成各类BI工具功能的平台化应用，在平台内同化各类BI产品后，给予客户更大范围的选择空间。微服务架构的高度可复用性决定了它可以通过组装客户所需的各类BI工具的功能组件，打造最适用于客户的BI体系。这将使得BI体系的丰富度和自由度得到极大提升。

　　3.B平台生态内的自动迭代。微服务架构在将功能模块实现独立开发独立应用的基础上，使得BI体系具备更细的功能粒度，这也将催生出真正的系统生态。用户将有能力在已有功能的基础上，对特定功能进行改造和升级，而这对于微服务架构而言并不会影响整体的稳定性。这样，整个BI体系内就有可能产生独立于原有功能之外的新功能，实现了生态系统内的自我繁衍和自我迭代。例如数聚的SEMF产品和Microstrategy都支持在原生系统架构上独立地增加企业定制化的功能甚至复杂应用。