应用架构的演进

最近被一个可爱的热爱技术的客户一直追问我应用系统的架构的相关问题，其实我也是一知半解，大概跟他解释了一下我所看到的应用系统的架构演进的一些情况，以及做架构设计的一些建议。客户满意离去，留下我一地鸡毛，随手记录下来以备不时之需。

一、应用架构的基本理解

首先来说，应用架构有两层含义，一是企业级应用架构，也就是EA的概念 ，企业层面的应用架构起到了承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。更关注企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

还有一层含义是单系统的应用架构，主要是单系统的实现逻辑和组成架构，从前端展示到业务处理逻辑，到后台数据，整体设计需要遵循企业总体应用架构原则。

二、应用架构的演进

我们首先应该明确，应用架构是为谁服务的，应用架构一定是为业务服务的，应该是围绕业务需求展开的，从需求出发利用各种新技术做架构上的演进和优化，而不是为了技术而改变架构。先进的复杂的架构不一定谁都承受的起。应用架构演进的提法和实践，其实也是互联网公司一直在推动，从小到大，从集中到分散，是一个渐进明细的过程：

1、垂直应用架构：

其实可以简单理解成单体应用架构，早起业务流量小，对资源的需求也小，所有的应用打包在一起，部署一台物理机上，可以跑得很流畅。后来怕不安全，为了保险，我们做了主备，可以实现部分高可用。再后来流量上来了，先考虑把数据部分拆走，我有了app和db分开部署的模式。再后来我们用F5或者Nginx等实现应用服务的负载均衡，这样的架构陪我们走过了很多年，直到现在还能在客户那里见到，就算上云了，也摆脱不了单一应用的架构。不是说单体应用一定不好，只要跟业务配合的好，谁不喜欢简单的东西呢。

2、分布式部署

业务越来越复杂，单体应用已经不能满足生产的需求，我们开始考虑把一部分应用功能分开部署，其实也许是组织架构的复杂性带来的系统复杂性，康威定律在发挥作用。系统各模块分开部署以后必然带来协同工作的问题，于是我们有了RPC和消息中间件等办法，来解决这个问题。要是说起PRC和MQ的区别，这个话题有点长，其实简单说，RPC侧重于功能调用考虑，多为同步方式，MQ主要是面向性能的，多为异步。RPC和MQ看似不是一个层面的东西，但是却能解决很多共性的问题，比如分布式、解耦等等，区别只是实现的方式和效果。

3、SOA

本来不想把SOA单独说，SOA跟分布式紧密相关。SOA是一种找到现在依然适用的架构理念，不是技术，却指导技术如何落地。SOA架构的特点就是服务中心，随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。

4、微服务

系统的复杂度到了一定程度，就必然会进一步拆分。微服务的目的是进行有效的拆分应用，实现敏捷开发和部署。拆分以后的服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

三、一些想法

我始终觉得，适合自己的才是最好的，假如你的业务负载始终比较稳定，业务逻辑也比较清晰，那你保持单体应用的架构也不是不可以。你的业务压力如果变化剧烈，新需求层出不穷，就算你不想改应用架构估计也不行。盲目追新和故步自封都不可取。

话有说回来了，从这个层面来看，有一个清晰明确的IT规划蓝图还是非常重要和必要的。