数字化浪潮下的架构融合浅谈

随着微服务架构的迅速蹿红，这颗新的“银弹”又给市场注入了巨大的想象力。人们在传统的交付和运维苦海中挣扎着，怎么加班交付都不够敏捷，怎么解耦应用都还是一团乱麻，怎么监控生产都还是如履薄冰。与微服务相对的巨石架构随即躺枪成为了万恶之源，如过街老鼠人人喊打。

然而如果我们稍微研究一下微服务架构的历史沿革和实质，会发现其关键强调的是一种架构和交付的文化，“微”的目的是为了服务能够独立、自治的垂直演进。记得曾经有一种非常有趣的说法，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两张批萨就够了，这是就是著名的“Two pizza team”原则。在这种模式之下，devOps几乎毫无例外的是刚需。然而如果仅仅是教条地将微服务作为一种普遍性准则，不分场合，生搬硬套，同样会遭遇尴尬。在实践中，人们往往最多的问题就是，找不到传统应用重构为微服务的合适场景。而且这种架构和交付方式对于经典的组织结构和文化也造成了极大的冲击。如何跳出传统的红海(苦海)的束缚，找到一片业务和架构的蓝海，成为了很多实践者关心的话题。

回到“骨感”的现实中，对于传统企业而言，微服务的采纳有可能并不是一个最急迫的核心问题。而且我们相信经过这么多年应用的治理，在一个有一定水准的企业内，巨石架构的弊端也没有外界想象那么严重。但是在实践中，必须承认服务化治理本身的确是一个既急迫又长期的过程，自SOA时代以来落下的功课早晚是要交上的。“高内聚、低耦合”在什么时代都是服务的黄金法则。

我们在前面曾经提到过，主机架构对于应用有着更大的包容性。这一点在服务治理的历程中是可以得到印证的。记得十几年前，IBM就建议主机CICS的用户在部署应用时，尽量将长交易、短交易，不同业务目标的应用分配部署到不同群组的CICS容器(region)中去。这样可以利用系统对于混杂工作负载的调度管理能力，充分地利用系统资源。然而这么多年过去了，大多数国内银行的主机用户仍然利用着系统尚充裕的垂直扩展性，保持着近乎极简的部署模式。不少用户不分或者极少划分业务群组，在每个CICS容器中都部署近乎全量的应用，并通过外围路由来区分不同类型的访问请求。这样的做法从积极的意义上，可以认为充分利用了系统架构的优势，简化了开发、部署和运维，并通过架构的包容性为服务治理争取了时间。然而，人们也应该意识到，这样的架构如果平移到另外一个所谓的分布式应用平台，其结果将是灾难的。

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!