谈谈业务与架构的关系

一、业务决定架构，架构推动业务

所谓架构的本质就是业务在落地过程中的最佳实践，架构跟业务也是互相成就的一个过程。在IT的洪荒时代，那时候车马慢一生只够爱一个人，对不起，串台了，那时候数据量小业务访问量也小，单体架构和独立服务器及能满足需求，后来数据量大了访问也上去了，于是有了负载均衡有了HA应用也开始按照模式进行部署，再后来压力达到已有算力不能支撑，于是有了云有了分布式。拿电商系统来说，电商系统属于长流程的复杂系统，复杂的业务场景催生了架构层面更加关注松耦合和可扩展性，映射到架构上也就是对微服务和消息队列的采用，高负载也迫使架构层面更侧重对吞吐的优化。所以说架构从来不会独立存在，是关乎业务场景。需求的场景化是架构设计的关键。

二、中台到底是什么

中台这个东西现在属于过度热炒，我们还是应该冷静的去看待。中台给需求侧了一个上帝视角，一下子把原来混沌的需求说清楚了，这就是中台的最大贡献。我更倾向把中台分成两部分，一部分是偏基础能力，是具体共性的技术环境，你可以管它叫基础paas或者ipaas、技术中台，随你喜欢；一部分是具有业务共性的部分，这部分是真正的中台，可以叫它业务中台，实际上是从业务系统下沉下来的共性部分。这两部分来说，越靠近技术相对越容易解决，越靠近业务越难解决，需要更高的视角和层次。微服务和中台又是什么关系呢，其实微服务是中台的实现方式之一，但不是唯一方式，微服务实现了技术能力的复用，实现了松耦合，使得系统更容易进行中台化改造。

三、云原生是咋回事

Pivotal很早提出云原生的概念，其实是脱胎于架构和咨询经验，总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，我们通常所说的DevOps、CI/CD、微服务、容器等敏捷的云资源等等都在里面。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。这就是初衷。 云原生并非把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅是基础设施和平台的事情，应用也要做出改变，应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩。也许很多客户会有疑问，会认为云原生是为互联网行业准备的，不一定适合传统行业。其实，云原生作为一种架构准则，适合任何行业。 云原生不是一个具象化的产品，而是一种架构思路和技术体系，随着云落地和发展，也必将成为未来的主流，影响深远。