作者：毕玄
文章来源：微信公众号HelloJava
之前写《回顾过去看应用PaaS的Next》那篇里提到了好几种架构，更多的还是自己所经历的，最近和一些人聊天，突然间发现一个可怕的事实是，现在的自己可能没在做主流架构了，那么在我们聊天YY里我们认为的主流架构是什么呢，这篇文章就来写写这个。
一家大公司演进的架构，一定程度上会代表主流架构的演进方向，但同时也不一定，原因是大公司很多时候之所以进行架构级的演进，是因为规模带来的伸缩性、成本的问题，而这些说实话对于多数公司而言还不至于，毕竟一个版本的架构能支撑到的规模通常是不小的。
回到正题，来YY下大多数企业的主流架构，如果不在以下范畴的欢迎回复打脸，:)
我们以通常一家公司的软件来看，最初做软件主要更多的是为了信息化，固定流程，串接起运转，这类型的系统呢多数不会太复杂，多数采用类似的单体式的应用架构就可以了，我觉得这类型的架构师还是有很大诉求的，不过我会更觉得对这类架构师更主要的诉求是在对业务的理解上而非技术上。
基本是发展了一段时间后，一家公司里就会出现好多个软件，这些软件彼此独立，但后来会发现如果能互通起来对效率会有很大帮助，所以就又会向前演进下通过API等方式来实现互通，这个时候对架构师的要求会有些提升，因为引入了分布式，尤其是当这种场景下出现了一些问题的时候，就比之前单体式的架构会复杂很多。
多数公司里的软件估计就这样的结构就可以运行很长时间，后来可能会触碰到一些新的问题，例如发现几个软件里都有一些相同的数据但不同的数据存储结构，类似的业务逻辑，相同数据到处重复，一方面影响效率，另一方面更麻烦的是数据一致很难保证，这个对公司的业务可能会产生一些影响，这个时候有些公司就会产生动力，去把系统架构演进到现在非常流行的“中台”模式。
“中台”呢，和前面的几种架构很大的不同是，它不仅仅是技术层面的，还有组织层面的，因为“中台”意味着一些数据、业务的逻辑要收归到统一的几个团队，而其他团队是在这之上去构建业务系统的，这个对很多公司而言推进不是一件什么容易的事。
到了这个阶段呢，对架构师的要求就大幅上升了，怎么更好的抽象出共同的“中台”，去满足上面多种多样业务系统的诉求，老系统的数据、业务逻辑如何迁移，都不是容易的事。
随着大数据，AI的起来，更多的公司也开始尝试借助这两方面的技术来改进业务系统，创造业务价值，很多公司会发现原来如果一些数字数对了，将能对业务效率等带来很大的帮助，同时也会进一步发现有了这些数据后，再结合智能能给业务玩法带来一些变化，但落地时就会发现无论是大数据，还是AI，前提都是有数据，并且能集中统一，这种情况下就会发现前面的“中台"模式是个挺大的前提（想想数据都四处分散，格式各种各样，还不一致，这让大数据，AI怎么玩）。
而随着云起来并且成为了现在大众都能接受的东西后，上面的系统架构设计其实发生了一个挺大的改变，架构师们开始要逐步的改变为结合云产品来合理设计自己的业务系统，这种我才认为是真正的Cloud Native架构，以一张著名的也是最典型的Cloud Native架构鼻祖Netflix的架构图举例：
图片来源于：http://blog.programmableweb.com/wp-content/netflix-systems-cloud-api.png
上面说到的除了单体式架构不太需要一些复杂的技术组件/框架外，其他都有这个诉求，在云之前要么基于开源，要么自研，而在云时代，这个则可以变成用云产品（当然，这也是一个权衡选择，但大趋势上我相信是越来越多的用云产品），所以对于这种场景下的架构师们而言，对云产品的熟练掌握，并结合云产品的能力来设计业务系统，就成为了新的挑战，云冲击到了上面除了单体式架构的上有场景，所以我认为现在开始以及未来五年内的主流架构师都会是非常擅长结合云产品能力来设计业务系统的一帮，这也是为什么我说觉得自己越来越不是主流架构师了，对于多数基于自研为主的架构师而言都将面临这个问题，当然，这个转变的难度不会那么的大，但需要有这个主动的意识和实际的尝试，避免到了某一天量变引发质变。
以我的YY来说，我认为大多数企业之所以有动力去改进现有系统，或做全新的系统，多数的动力都来源于效率，通过新的系统来大幅提升企业的运转效率，服务客户的效率等，这显然和很多大公司的架构演进是完全不一样的，当然，有可能在架构上大家是同样的，例如分布式架构等，但诉求不一样其实就决定了在架构设计时要关注的点的巨大不同，也非常希望有同学能回复说说你的case，你所做的系统为什么会重构、为什么会重新做一套呢，诉求是什么？
