79 lines
5.7 KiB
Markdown
79 lines
5.7 KiB
Markdown
|
||
# 中台
|
||
|
||
```
|
||
聪明的人把复杂问题变简单，愚蠢的人把简单问题变复杂。
|
||
|
||
我们的任务就是无限逼近原材料的成本，因为除了原材料成本之外，其它成本都是人类协作过程之中产生的，就有可能被消除掉，从而逼近原材料成本。
|
||
马斯克眼中的第一性原理--回到事物的物理本质
|
||
```
|
||
|
||
### 中台
|
||
中台这个理念不知道是不是阿里提出，但是阿里炒热的，后来是大家一起炒，互联网公司热衷炒概念，一波接一波。
|
||
中台其名就如同新零售，这些名字并不反映技术本质特征，但朗朗上口，易记易传播，不像OO、AOP、MVC、微服务、服务治理...那么拗口虽然更能反映技术的本质。
|
||
是个筐，把现实中需要解决的问题和漂亮实用框架、快速响应、敏捷创新的理念往这个框里扔就是，:walking:至于名字叫"中台"、"综台"，甚至"总部"并无所谓了。
|
||
个人理解更多的一组概念，或者一套方法论，具体服务于这套方法论还是看解决的问题块，选择落地的技术框架。
|
||
这些理念的提出基于某些现实问题，并结合开源社区的先进思想，及最佳实践，都是不错，对于阿里这样的企业也许有现实作用。
|
||
|
||
### WHY :question:
|
||
- 前后台深度耦合:shit:臃肿
|
||
- 开发效率
|
||
- 沟通成本:shit:程序员最懂业务逻辑
|
||
- 能力复用、协调、组合 :point_right: 快速创新
|
||
- 武器库，开箱即用
|
||
- 快速响应
|
||
- 快速掉头
|
||
- 降低试错成本, 鼓励试错
|
||
|
||
### 中台的核心
|
||
- 提出所谓中台主要基于两方面:
|
||
- 治理的需要，企业大必定顽疾多，搭建之初，更多考虑如何响应前台需求，<bk>
|
||
没有良好重构的业务或功能也必定存在，积重难返，必须加速治理
|
||
- 新动能需要，阿里的开源生态是不错 <bk>
|
||
(题外:别看华为近期搞得热闹，个人觉得开源生态还是阿里高出太多，可以参考国内外统计 [ref1](https://www.infoq.cn/article/G4O6JUhJF*Tsv9eWM0L6) [ref2](https://www.freecodecamp.org/news/the-top-contributors-to-github-2017-be98ab854e87/)，这个确实很能说明企业文化，阿里的领导这方面相当有水平和前瞻性，HW如果在开源上的用劲都能像余大嘴的牛皮般，相信赶上也只是时间问题:laughing:) <br>
|
||
阿里自己用了很多业界开源成果，自己也造了许多轮子，这就有个复用、组合、协调以适应快速创新和高效运维的要求了。<br>
|
||
中台概念之于这样的企业，在于止血化瘀，活化组织。所以大企业中台就不光是技术架构问题，还有业务中台，组织中台。<br>
|
||
而对于小企业是如何选择一个好的框架的问题，就三板斧，那就是一下货三下的问题，不存在太多选择，用业界成熟最佳实践就是了
|
||
|
||
```
|
||
数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
|
||
```
|
||
|
||
- 大中台
|
||
- 乒器谱有的随你挑，核心要义是能力沉淀，包打天下，与前端彻底解耦，开放很重要，做好权限控制后，我其实并不关心谁来怎么用
|
||
- 小前台
|
||
- 依托大中台能力，只需做少量前端特色服务定制
|
||
- 前台可以碎片化，不同业务场景都可以有前台，前台可以根据市场变化快速进入，也可以快速退出，可以原型、可以试错
|
||
- 核心要义是灵活、快速
|
||
|
||
### 架构目标
|
||
- 业务中台采用领域驱动设计（DDD），在其上构建业务能力SAAS，持续不断进行迭代演进。
|
||
- 平台化定位，进行了业务隔离设计，方便一套系统支撑不同玩法的业务类型和便于定制化扩展。
|
||
- 前后端分离，通过服务接入层进行路由适配转发。
|
||
- 天然的分库分表，消息解耦和分布式缓存设计，支持弹性扩容，以支持大数据高并发场景。
|
||
- 减少沟通成本，提升协作效率，制定标准和规范，集中管控，分布式执行。
|
||
|
||
中国电信7000个APP可以说都是烟囱式，每一根烟囱都是孤立的垂直技术堆栈，为了响应一个新的需要要么是在加高某根烟囱，要么是再造一根。
|
||
|
||
产品开发之初，特别是早期开发的产品，在前端看来可能是成功的，前端的越成功越意味着业务驱动平台，早期没有太优的架构下，为了快速响应往往是前后台交织，运维来保证robust，而不是架构本身。这样带来至少三个弊端，一是小烟囱太多，复用困难的，且不便于治理，二是无法形成新的组合应对快速创新，三是不便运维，程序员更迭可能意味着代码死亡。
|
||
|
||
谈中台是企业信息化建设持续进展和业务不断创新，以大量的基础沉淀为前提的
|
||
凭空搞个大中台，显然是理想状态，空谈
|
||
|
||
微服务作为中台的一个技术手段
|
||
|
||
高内聚、低耦合、职责、边界清晰
|
||
|
||
基础能力聚合，要求高，
|
||
|
||
中台最终是开放给别人用的，别人用的好了，就成功了，这里最多备用的就是前台，中台为前台快速提供能力，前台想不想用，爱不爱用，好不好用，帮了前台多大的忙，从中台获得了多大的好处，愿意掏出多少利润来帮助建设中台，这才是甄别中台建设对错好坏的唯一标准。 **对于中台来讲，前台就是用户，以用户为中心，在中台同样适用**。
|
||
|
||
|
||
### Refrences
|
||
1. [ref1](https://www.infoq.cn/article/G4O6JUhJF*Tsv9eWM0L6)
|
||
1. [ref2](https://www.freecodecamp.org/news/the-top-contributors-to-github-2017-be98ab854e87/)
|
||
1. [中台平台架构资料整理](https://www.douban.com/note/705218329/)
|
||
1. [我花10个小时，写出了小白也能看懂的阿里数据中台分析](https://www.jianshu.com/p/05a8db84e454)
|
||
|
||
|