https://book.douban.com/people/fleure/annotation/27039508/
- 业务中台对前端核心业务的紧密沟通机制
各服务中心的核心架构师和运营人员会定期参与前端业务方的业务会议（比如周会）或重要项目的研讨会（比如双11大促），通过这样的方式，让业务中台对于前端重要的业务发展动向有一个准确、及时地了解
- 建立分歧升级机制
出现中台与前端应用的争执时，一般按照业务负责的层级关系依次升级。… 通过这样的升级机制，将出现的分歧在更高的层面上与前端应用方达成一致。对于这样的分歧处理一般在部门层面为止，比如天猫事业部和共享业务事业部层面，不会到更高的层面，毕竟是比较具体的业务。
- 岗位轮转推动真正换位思考
虽然采用业务分歧升级的机制，很大程度上解决了中台部门与前端应用方在协作过程中产生的分歧，但总体来说，因为前、中台人员所处岗位的不同，依然避免不了针对业务在哪里落地产生争执，如果遇到双方都是强势领导的时候，就会将一些本应内部通过协调沟通的问题暴露在了业务更高的层面，从而在某种程度上影响了业务中台与前端业务方的协同效率。
所以阿里巴巴也会在一段时间内采用岗位轮换的方式，比如将业务中台某服务中心的负责人与天猫对口业务的负责人进行岗位对调，让双方在世纪工作中更真切地感知到处于不同岗位时对业务的理解和出发点。
- 业务持续沉淀及共建模式
在进行业务沉淀到中台的过程中，又会出现两种情况，一是业务中台现有的人员对于要沉淀的业务功能自身就有较强的业务能力，能够很好地完成将业务功能沉淀和融入到业务中台的能力，这样一种方式是目前很多前端业务功能沉淀到中台的典型方式；另一种情况则是对于要沉淀到业务中台的业务，业务中台现有人员没有足够的业务理解和能力，此时，就会采用共建的模式，业务中台和前端应用方格子派出人员共同组建一个团队，一起负责该业务功能的实现以及到中台的能力沉淀。
这里给大家介绍的是在数据库层面实现异构索引的方式，也是阿里巴巴内部目前采用的方式，通过一款名为精卫填海的产品实现了数据的异构复制。本质上精卫是一个基于 MySQL 的实时数据复制框架，可以通过图形界面配置的方式就可以实现异构数据复制的需求。除了在同步异构索引数据的场景外，可以认为精卫是一个 MySQL 数据触发器+分发管道。
大约跟 maxwell 是一回事。对shard过的库解析binlog，按另一个维度冗余索引数据+ shard。
如果在“尽量减少事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则，因为事务便捷的问题相对来说更好解决，无论是做全表扫描或做异构索引复制都是可以解决的。而写入或单机容量如果出现不均衡，那么处理起来难度就比较大。
尽管复杂的切分规则或数据的异构索引能够给系统的性能和扩展性带来显著的收益，但其后面所带来的系统运维复杂度上升也是不能忽视的一个结果。
如果为每一个存在跨 join 或全表的场景都采用数据异构索引的方式，整个数据库出现大量数据冗余，数据一致性的保障也会带来挑战，同时数据库间的业务逻辑关系也变得非常复杂，给数据库运维带来困难和风险，从而对数据库运维人员的要求和依赖会非常高，所以从系统风险的角度考虑，以 28 法则，在实际中，我们仅针对那些在 80% 情况下访问的那 20% 的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对其他 80% 偶尔出现跨库 join、全表扫描的场景，采用最为简单直接的方式往往就是最有效的手段。
里面提的“全表扫描”其实是sql代理层给所有shard同时发query再对结果做聚合的做法。
好的创新一定是基于企业的现状因地制宜，而这决定了在很大程度上企业的创新会来自企业内部，而且提出创新的人一定是对行业有过人的认识和理解，才有可能提出创新的想法。
虽然现在各个行业都在进行跨界的创新，比如互联网公司去做汽车，家用电器厂商去做手机，但这样的创新存在着很多不确定的因素，其中存在的风险是一般企业所不能承受的，也非常态化的创新。对于大多数企业，眼前能做的创新还是行业内的创新，这样的创新更多情况下是依赖对企业所在行业称得上专家的人，这样的人在行业的特定领域一定有相比普通人更深的理解和认识，才能提出普通人想不到的创新。
“烟囱式”系统方式以及 SOA “项目制” 的建设方式导致了前面所说的第三个弊端：“业务得不到沉淀和持续发展”，从而造成服务不能真正成为可重用的组件，为业务的快速响应、支持业务快速创新带来的业务价值。究其原因“烟囱式”系统建设模式是导火索，ESB 在其中扮演了原本它擅长的工作，ESB也没有错。而错在SOA项目是基于一种集成项目建设的方式，就很容易造成服务提供者面对业务提出更多要求时，考核指标、工作回报都不能得到很好体现，服务提供者在主观上没有太大的积极性满足新的业务需求，再加上如果当初服务设计的功能扩展性和业务前瞻性不足，导致有心无力满足新的需求，结果是这些服务无法再进行功能扩展，成为企业“业务稳定”运行的“服务”。
1）重复功能建设和维护带来的重复投资。.. 单单从开发和运维两方面成本投入的考虑，对于企业来说就是一种很显性的成本投入的角度，对于企业来说就是一种很显性的成本和资源浪费。但这一点对企业带来的伤害却是最小的，只是成本的损失。
2）打通“烟囱式”系统间交互的集成和协作成本高昂。
3）不利于业务的沉淀和持续发展。从传统 IT 系统建设的生命周期来看，一旦系统上线以后，就进入了运维阶段。在运维阶段，也会有对系统功能完善和新业务需求的升级；因此我们看到了平均周期在几个月，甚至半年进行一次功能的升级。而事实上业务的需求时与日俱增的
不可否认 ESB 的架构很好地屏蔽了服务接口变化给服务消费者带来的影响，是解决不同系统间实现互联互通的很好的架构，但这样的项目再企业中落地后，后面的发展就让 SOA 价值的体现出本末倒置的现象！… 企业实施 SOA 集成项目上线后，各个系统按照标准封装的这些“服务”就进入一个“稳定”状态。这里的“稳定”当然不是指服务运行的稳定，而是这些服务对外提供的功能变得“稳定”，也就是说，很多服务在初次上线后，在接下来几年的时间里就几乎没有新的服务功能的增加或提升。
现有企业内 SOA “项目制” 建设的效果最终导致三个弊端，而其中第三个弊端“IT系统建设中实现的业务得不到沉淀和持续发展”是对企业伤害最大的。
如果说过去，业务需求的增长态势还算比较平滑，没有体现出系统的响应能力有多大差距，那么在今天，互联网时代业务需求的增长越来越迅猛，原有系统对业务响应的能力就显得更加捉襟见肘。到了一个时间点，量变产生质变，就会出现企业核心业务系统运行多年后被推倒重来的现象。
我承认在对业务系统的具体流程、操作、数据模型方面IT人员比业务部门更懂，因为这些系统是IT人员负责建设的，但我所说的懂业务是指，能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。
但接下来的发展却事与愿违。虽然组织架构上共享业务事业部和淘宝、天猫平级，但从对业务的理解和业务贡献的体现来说，淘宝和天猫对共享业务事业部拥有更多的话语权，结果就是共享业务事业部在两大业务部门的业务需求下艰难生存着。到此，共享业务事业部的产生和发展确实与大部分人的期望有着很大的偏差。
真正带来转折的是2010年，作为阿里电商业务的团购入口——聚划算的出现。聚划算平台刚一上线，就展现它强大的流量吸引的威力，据不完全统计，不管是淘宝还是天猫的商品，一旦进入聚划算平台，销售额会在短时间内增长25倍，聚划算对于淘宝和天猫的运营人员来说，无疑是一个增加流水的有效途径，所以一时间大家趋之若鹜，纷纷对接聚划算平台。
这时就出现了对共享业务事业部历史转折点的一个举措，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享业务事业部。