Cognos只是一个工具，说到Cognos相信大部分人都知道BI（商业智能，Business Intelligence）。
Cognos也是属于SOA架构，面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约
- 1
- 2
联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，
当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
- 1
- 2
- 3
如下图所示就是Cognos的组织架构图。
从上至下分别为：展示层，应用层，数据层
展示层：
IBM Cognos Gateway组件：这个网关，是用户访问Cognos之间的桥梁。对用户提供的信息进行加密，并且可以把用户的请求进行分解，加上自己Web
层中的环境变量传递给后端应用层服务进行处理。确保用户请求是有效的，而不是非法进入访问。另外一方面，可以有效的防止Cognos暴露在外面，
配合应用层防火墙拦截非法请求。同时他也可以有效的为主要的Cognos服务（IBM Cognos Content Manager）分摊压力，对用户请求进行分派。
- 1
- 2
- 3
- 4
应用层：
应用层是Cognos的任务控制中心。是所有请求处理中心，包括用户请求，交互式请求，批处理请求，后台调度请求等。他会以最佳的方式来分发请求，
并提供服务。应用层分为两种服务器：Cognos Content Manager 和 Cognos Report Server.
Cognos Report Server顾名思义就是用来处理报表的，他可以请求元数据，对报表展示数据的。
Cognos Content Manager 是整个Cognos控制中心，主要用来管理元数据库 ( cognos content store)，元数据库中存储了用户的应用数据，包括
安全信息，配置信息，模型，报表，报表输出版本等等。 content manager 用于发布最新模型，获取报表定义，管理调度信息，管理用户名称空间等
等。同时还管理着任务分派器dispatcher，任务分派器，接收到gateway用户请求时，他会在content manager服务中注册信息，他会根据每个分派器的
处理能力来判断请求是在本地处理还是给其他分派器进行处理。另外分配器中都带着应用防火墙，为Cognos服务提供了一个安全保障。
Content Manager是我们整个Cognos的大脑，只要他还能运作，其他服务都停止了，他也能正常工作，但是他一旦出问题，Cognos也就意味着崩溃了。
所以在配置负载均衡时要考虑Content Manager所在服务器的配置是否合理。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
数据层：
security namespace其实就是Cognos所连接的第三方认证源，可以是windows,Apache等等。所有用户的认证，授权都是靠他来实现的。
content manager 与content store元数据库是使用JDBC的方式进行交互的。所以在安装的时候需要拷贝相应的JDBC驱动包到相应的路径下（ojdbc14.jar/ojdbc6.jar/class12.jar）,db2,oracle需要拷贝，而sql server不用，因为cognos自带这个数据库的驱动包。然后就是还有Report server所连接的data source 和OLAP,通常报表连接的data source 所采用的是客户端提供的native方式进行连接，所以这时就需要安装一个32位的客户端对data source 进行连接。这种native连接方式要比JDBC连接方式更有效率。
四种常见的COGNOS负载均衡方式：
常见架构实例：
from https://blog.csdn.net/yangpingping94/article/details/72810438