最近关注的一些核心技术问题

最近关注的一些核心技术问题，有相关资料的可以帮忙推荐。

MySQL数据库层面

关心MySQL读写分离集群和Cluster集群的选择策略，Cluster集群虽然具有完整的热备份能力，但是由于数据shading将导致很多问题，特别是跨数据节点的多表关联查询性能，在该问题解决后又出现的问题是对于数据集成和BI需求的满足上，是否一定要基于Hive模式来实现相应的需求？还是说多数据节点数据最终还得抽取到一个集中的ODS或DW中。对于读写分离集群，关注数据复制技术，虽然是基于BingLog的亚秒级日志复制，但是仍然关注对于多个读节点下，采用悲观事务模型下对于Master库的更新问题。还有就是如果采用读写分离集群，如何根据前期的业务量测算来考虑如何进行分区和分库，如果在分区和分库后master库仍然存在性能瓶颈的时候如何解决？这些都是问题。

在Cluster集群下，可以实现99.999 ％的高可用性，完全避免单点故障，水平线性扩展。但是Cluster集群基于前端的一个内存数据库，对内存的消耗量究竟有多大？对于单数据节点的容量限制究竟是多少？另外网上谈到的数据行不能超过8K（不包括BLOB和text中的数据）限制是否有？暂时都还未知。现在对于大型的Cluster集群使用是否有案例？经初步了解淘宝现在基本仍然采用的是读写分离集群+分库的方式。

在读写分离集群下，如果使用MySQL-Proxy，那么对于路由或代理服务器本身在大并发下是否存在性能问题。如果不采用Proxy代理采用硬件负载均衡如何对Request请求进行负载均衡。我们在考虑的时候是想显示的来实现数据库连接的获取和均衡，避免Sql解析引起的性能消耗。那么必然涉及到类似于讨论tddl层的设计和实现。

MySQL和异构数据库之间的同步和数据集成问题，现在基本Oracle ODI 11g自带的mysql->oracle的知识模块可以很好的解决这个问题。具体性能如何还有待验证，但是基本清楚的是对于源和目标数据库都必须要采用源生的批量数据导入和导出接口。对于cluster库如何处理还没有进一步想清楚。

采用了MySQL集群数据库后，代理的集群数据库的管理和监控问题，数据库的日常运维和备份等问题都将面临重大考验。这也是很多时候开源虽然软件层面省了钱，后续运维监控往往投入更大。

SOA和ESB层面

对于ESB层面我们仍然最关心性能问题，在前两年的测试数据里面对于Oracle SOA 11g套件中的OSB基本可以达到2000-4000TPS的性能，但是基本没有太多的数据映射转换和路由等，而且数据量的传递基本也都在50K以下。那么对于在大并发，较大的数据量和消息体传输下OSB的性能仍然是必须要考虑的问题。对于大数据量我们采用的是类似Proxy的解决方案，包括ODI等各种解决模式，对于大并发则考虑的仍然基于硬件设备的负载均衡。

在ESB集群的构建模式下，完全可以避免N-1节点故障，由于ESB每次服务调用本身完全无状态，很多时候我们一直在考虑数据库本身是否需要完全分布式的问题。如果数据库层也完全分布式，则并发问题可以完全做到水平线性扩展，唯一的就是服务运行监控和分析需要抽取统一的ODS库，其他没有太多缺陷。

ESB本身是涵盖了消息中间件的内容，基于消息的集成往往更容易实现系统和组件间的彻底解耦，包括消息本身的持久化，重试，消息分段压缩，消息的订阅和发布机制等。服务集成和消息集成各自都有适用场景，在后续实施中重点加强消息集成和EDA事件驱动架构的使用。由传统的面向流程转换到面向流程+面向事件相结合。

对于ESB服务集成，服务模拟器，服务的自动化测试是另外重点考虑的内容，一切都是为了解耦下的并行，并行后的自动化以提升效率。

基于ESB集成模式下，业务系统完全组件化架构，组件间通过业务服务进行交互和集成，那么后续整个应用的集成，集成测试，集成的具体策略和顺序又成为重点考虑的问题。大系统的集成如何和每日构建和持续集成策略，配置管理更好的融合，形成完整的产品集成框架也显得更加重要。

大数据的集成是另外一个考虑的问题，对于数据服务和数据集成，采用ODI模式来实现，对于ODI模式本身不支持并发比较头疼。另外ODI模式下的性能是重点考虑的内容，研究ODI下的各种知识模块的使用策略和使用场景可以很好的解决ODI模式下的性能问题。

不管是使用OSB还是BPEL，不仅仅是说解决遗留系统的适配，路由，消息协议转换，更加重要的实例和日志的记录问题。跨系统或组件的集成必须对于每次消息或服务调用都用详细的日志记录，以方便后续对接口问题进行详细的日志分析和排查。经过我们测量，对于增加日志记录节点要额外消耗50%的时间，确实又是一个头疼问题。

应用设计的问题

当我们在谈云的时候首先想到的就是集中化资源，但是集中化后本身为了解决水平扩展问题又变化为分布式架构。在分布式模式下CAP模式不能兼得，自然引发出更多的需要考虑的问题。

首先是分布式事务的问题，对于分布式事务建议策略还是不需要采用太重的分布式事务管理框架，要区别对待我们对分布式事务的需求，如果BASE策略使用那么一定采用BASE策略来实现最终一致性。那么基于消息队列和消息中间件架构下的分布式事务替代模式完全是可以接受的。这种模式往往比简单的事务补偿模式更好。但是具体如何使用还需要根据业务场景来细化设计。

在分布式后带来的第二个问题就是前面讲到过的统计分析和BI需求的满足问题，特别是数据进行shading后如何实现统计分析需求。是否必须要采用HIVE等架构来解决分布式的查询统计分析？

原来我们进行的系统分析和设计都不是基于分布式和云架构进行的，如果我们基于分布式架构下，基于SOA服务集成我们必然面临更多的内容。包括整个应用如何进行组件划分，如何进行分库以最大化的降低模块间的耦合。模块间应该如何进行交互和提供服务？对于跨库的查询问题如何解决以解决性能问题？这些都是原来集中化数据库下不会遇到的问题。

对于分库后每个模块还是标准的三层或多层架构，但是模块间的交互和集成策略已经发生和很大的变化，系统的组件化架构将SOA思想引入到了系统内，但是即使对于一个业务组件，我们仍然强调在内部实现spring+OSGI模式的软总线架构，以实现模块内的进一步解耦和热插拔。对于OSGI本身是否已经稳定成熟还有待进一步考验。

===============================================================================================

为了强调平台化和复用，资源的集中化和调度，我们对原有的业务系统构建进行的水平分解和垂直分解，通过水平分解对可复用的内容进行平台化和下沉，通过垂直分解都系统进行模块化和解耦。这些确实最大的提升了平台化和复用程度，但是带来的问题确是原有紧耦合下单方可以完成的工作需要多方协同，多点集成才能完成。分解往往不是难点，最终的集成却异常复杂。正如做一个系统的架构设计一样，分解不是能力，分解后的组件能够很好的集成才是能力和价值。

   青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密