最近公司做了一次IT应用架构的重构和升级，整个流程走下来，收获颇丰，在这里略作总结，以备后查。
阶段一：烟囱式
公司老的IT架构属于传统的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。见下图：
阶段一-烟囱式架构.png
我想这也是许多传统企业的IT架构的样子，这样的架构有几个主要的弊端：
- 重复开发。每个业务线中间同样的模块会重复开发，比如会员营销模块，A业务线要建一个会员营销系统，B业务线也要建一个会员营销系统，这会造成很大的开发资源浪费；
- 技术栈不统一。可能A系统用的是Spring MVC, B系统用的就是Spring Boot/Cloud。这会造成公司内部IT架构无法统一规划，且技术能力难以积累的问题；
- 数据无法打通。A系统的会员存在A系统的MySQL库中，B系统的会员存在B系统的Oracle库中，如果要识别A系统中的001会员和B系统中的002会员是同一个人，也许只能在数仓中实现了。
总结：这样的架构的好处就是可以互不影响地独立部署独立迭代了，适合业务线较少且比较独立的公司采用。
阶段二：平台
在清楚了烟囱式架构的弊端，且业务线越来越多的情况下，公司IT团队开始考虑平台化的架构，即提供一个统一的会员营销平台来管理全集团的会员，来配置全集团的营销活动，A系统和B系统的用户都在平台上进行操作：
平台化架构.png
在设计的过程中，我们逐渐发现，这样的架构对于像我们这样的老系统来说改造成本非常之大。举个例子，A系统有抽奖活动，特价活动这两种营销活动；B系统有抽奖活动，签到活动这两种营销活动。现在要做一个统一的会员营销平台，就是让管理者可以统一配置这两个系统的三种活动。但虽说都是抽奖活动，实则由于渠道、规则、限制、奖品等的不同，两种活动其实只是活动名称相同而已，具体的实现完全不同。最终造成的结果就是虽然是平台化了，但是实际上内部的实现还是根据具体的适用系统而走了不同的逻辑。虽然前端看起来是一个统一平台，但实际后端很大程度只是把原来两个系统的代码合并在了一起而已。对于原来两个系统独有的活动，也还是独立的去实现，并没有节省什么开发工作量，反而因为需要针对那些两个系统都存的在同类活动的合并而绞尽脑汁去抽象数据结构和逻辑流程，且一旦合并后，如果其中一个系统的活动逻辑需要调整，还可能影响到另一个系统的同类活动。
总结：这样的架构适合全新的IT应用，即从一开始就按平台化规划的应用架构，这样在设计之初就可以统一规划营销活动、会员属性等同台统一的属性。
阶段三：平台+中台
在被平台化搞得头大之时，大家转而想到了年初看过的一本《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》里提到的“中台”的概念。简单阐述下何为中台：中台思想即将不同业务中相同或相似的基础服务沉淀到统一的中台应用中，如将所有的业务中的会员服务沉淀为会员中台，将所有的业务中的订单服务沉淀为订单中台等。将原来的业务系统剥离为较薄的一层“前台”应用，只包含该业务系统特有的业务逻辑。这样做的好处有：
- 减少重复开发。每个系统不再需要开发单独的会员模块、订单模块等，全都可以直接调用相应的中台接口。
- 增加服务的复用性。能够沉淀到中台的必然是多个应用都能够适用的通用逻辑，自然保证了中台服务的复用性。
- 快速构建前台应用。如果要新增一个应用系统，只需要构建薄薄的一层前台应用即可上线，交付时间短，开发更加灵活。
- 数据打通。不同业务线的基础中台数据有相同的数据模型，可以统一调用。
正所谓它山之石可以攻玉，将中台的构建也纳入我们的IT应用架构中：首先将A/B系统中基础的会员营销服务沉淀到member中台中，基础的会员营销数据也沉淀在中台库中。同时将两个系统中可以统一的营销活动平台化，将两个系统中各自个性化的营销活动保留在原有的“前台”应用中，且前台应用直连业务库，可得架构图如下：
平台+中台
注：图中的member中台实际上是分为多个中心的，如会员中心，卡券中心等，下图同
但这样的设计还是有一些问题：
- 对于A、B系统的用户来说，他要配置一个营销活动，可能要去业务系统中配置，也可能去平台中配置，比较混乱；
- 对于平台化的营销活动，如果调整了逻辑会影响到所有应用系统；
- 由于A、B系统的需求都有专门的产品经理负责，且之后的需求也只会针对A、B系统分别提，那就会造成新的功能逻辑都分别在A、B前台系统上不停的生长，而没有专人负责平台的需求及后期规划。
其实，上面的第3点恰好道出了一条架构设计中很重要的定律——康威定律Conway’s law：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
放在IT架构中说白了就是系统架构需要与组织架构一一对应。这条大名鼎鼎的定律之前都是只闻其名，不知其实践。到这里我们像大彻大悟一般：除非平台有专门的业务部门负责（比如集团会员营销部之类的），否则就不应该存在。上面第3点的问题也正是因为统一平台缺乏对应的组织造成的，即应用架构与组织架构不匹配，违反了康威定律。
总结：平台并不是不可取，平台实际上也是一个前台应用，只不过需要有相应的业务部门（组织）负责，这样才是符合康威定律的架构设计。
阶段四：中台
这个阶段实际上就是把阶段三的平台给去掉。只留下了中台，以及能够找到组织架构中对应业务部门的前台应用：
中台
对于中台，还是将A、B系统的通用会员营销逻辑沉淀下去，如会员资产：积分、等级、优惠券、订单等。但对于特有的营销活动，还是保留在业务前台系统中分别实现。这样既保留了系统独立的业务自由度，也能将集团范围内的公共数据资产和服务通过中台思想进行沉淀。且当未来出现某个组织来统筹“平台”时，也可以在中台的基础上很快的构建。
以上就是最近我参与的一个IT架构改造的经历。总结成一句话：
没有最好的IT架构，只有最合适的。
网友评论