银行中后台与阿里中后台有何不同-读后感
文章来自于极客时间（https://time.geekbang.org/column/article/99731）
大体内容如下：
阿里的中台提高了服务的服用能力和开发效率，银行是否可以借鉴阿里构造通用框架？
如果可行，那么需要注意什么？
假设可行的情况下:
- 解决的是流程问题。
- 对于流程的抽象。
- 阿里具有行业业务的通用性很高，流程的高度可控性，可替换性。总之电商领域实在比较接近的流程下去寻找能力和服务上的特色
- 银行领域，虽然产品的同质化程度很高，但受制于行业本身的原因，各大银行的流程无法统一，原因在于以下几点
- 组织结构和部门利益
- 部门设置和职位边界
在这种背景下，银行的中台更多的是面向功能的沉降，在流程与功能解耦的原则下，将流程分离成微服务架构层
但是剥离可通用的能力作为中台服务层。
银行多以产品驱动，设计上其实并不是一定要以“客户为中心”这种导向而改变，因为产品即服务，服务即产品，并不需要太纠结（这个说法个人不太赞同）
产品通常意味着会驱动后台一些列服务和功能。在ESB下，这是不同服务间的信息流转。在没有大并发量及其严重堵塞的情况下，没有必要拿掉ESB。微服务和ESB是否互斥业界也是有不同声音的，消息队列下，其实一个产品就意味着相关服务的一组订阅发布。
可以将银行的产品按照较大的流程环节进行微服务切分，这种流程可能会在不同的银行间有差别，譬如，对某个业务A银行有预处理过程，而B银行没有。某个业务A银行可以1个部门完成，B银行需要几个部门协作完成。这些差异也许来自内部文化，也许来自规模。银行自己也会随规模和业务重点的变化而不断调整，其实提供的服务变化不大，但是流程可能变化巨大，所以流程环节设计成微服务层以满足快速变化。（部分观点不太赞成）
将相对稳定的功能，比如示例中的久期计算，缺口计算之类的较为通用，和评级计算，EVA这样相对有变化但不需要非得和流程搅在一起的功能沉降为中台，服务尽可能无状态以便于改造和迁移。
数据则是企业级后台。微服务的处理结果准时更新至企业级数据库，中台可以通过企业级数据库查询准时数据，实时数据则可由调用方提供。
银行学习互联网还应考虑一致性设计原则，阿里采用的是最终一致，银行采用的是强一致。
从企业文化和组织结构角度看，阿里的技术成长伴随阿里的文化共同成长。对于银行企业文化来说，应该还是很有挑战性的。
- 对于流程的抽象。
以下是我读过这篇文章的感受。
- 以客户为中心的设计，我觉得是跨行业的，跨规模的，也是企业是生存，发展，壮大的关键。就比如银行，银行提供的产品或者说服务，一定是迎合客户需求的，可以是定制高端，也可以是面向大众的。没有市场基础，不被市场认可的产品，注定会被市场所淘汰。
- 银行采用溯源策略和最终一致能否替代强一致？至少在UI设计上是可以分阶段显示状态，增强用户体验。
- 可移植的银行UI脚手架+定制化的银行主题+可扩展的功能UI，实现银行ui在PC,移动端的第三方化。
值得学习得微服务视频