首页手记从All-In-One到SOA—&mdas...

从All-In-One到SOA——技术及架构的演进过程（二）

标签：

设计

服务化演进过程之架构演进

随时间的发展，用户量逐步甚至是爆发性的增长，这样就给网站的承载能力带来了极大的挑战，必须探索新的架构方式以适应在用户增长后对网站响应速度、界面友好等方面的需要。因此促生了网站架构的几次大变迁。

1 单一应用
在诞生之初始，应用与数据库是部署在同一台机器上，这时的用户量、数据量规模都比较小，这样的架构既简单实用、便于维护，成本又低，成为了这个时代的主流架构方式（这种架构仍然存在，在一些小型应用或者实验环境仍是主流，主要还是成本与方便性的原因）。

随着安全意识的提高及技术的发展，数据与应用分离的呼声渐高，原始单一应用逐步转化为WebServer＋DatabaseServer的模式。这一阶段的发展已经走到的尽头。

2 垂直应用

当单一应用不能满足需求时（主要是响应速度与吞吐量），如何改变架构以应对实际问题呢？问题是推动技术发展的源动力，当问题出现时，总是会有响应的解决方案，垂直型应用架构在这种背景下出现了。

所谓垂直型应用架构，是指将一个大的单一应用拆分成若干个小的单一应用，这样每个应用的压力大约有原来的1/n（粗略估计值）。这种拆分方式为后来的技术发展奠定了基础，每次架构的变化都与这次有着密不可分的关系——分治（将一个大的问题按一定业务规则分成若干个小的问题，逐个解决）。

3 分布式架构

当垂直应用越来越多，业务上跨应用的交互不可避免，这给垂直应用架构带来了很大的挑战，如何才能进行跨应用的交互呢？RPC的出现解决了这个问题，RPC作为分布式架构的核心内容，在提高业务复用、业务整合、架构扩展等方面发挥着不可替代的作用。因为RPC的实现方式有很多种，单一语言、跨语言都存在相应的开源产品（当然也可以自建），这为RPC的使用及推广奠定了良好的基础。

此时需要注意，服务一定是无状态的、接口稳定的。

在分布式架构中，将剥离出来的核心业务构成的服务层相对独立、稳定，以这些服务为基础进行不同形式的组合使用，使前端（view、消费者）能够快速适应业务发展、变化。这时的前端架构也逐渐被从整体架构中剥离并越来越受到重视（尤其是移动应用的快速发展）。

4 SOA

分布式架构中的服务越来越多，导致交互越发复杂，不可避免会出现资源浪费的情况。如何才能更好的管理复杂的调用关系、提高资源利用率、对整个服务集群进行动态控制。服务治理被引入来解决上述问题。

通常服务治理包括：
1）通过注册中心管理所有服务（即服务注册于发现）；
2）路由选择、负载均衡及容错处理；
3）服务依赖关系；
4）监控与统计；
5）服务过滤（黑名单、白名单）；
6）服务升、降级，权重调整；
7）服务状态检测、监测；
8）服务权限控制。

如何在服务化架构中实现服务治理以及要对哪些内容进行治理，需要根据实际情况进行取舍，因为每个服务化架构中关注的内容可能都会有所不同。治理的实现方案也没有统一的方案、规范，在能满足自身需要的前提下，尽量避免过度管理、控制。下面是一些建议：
1）服务注册与发现，能做到自动化最好，尽量少的人工干预会给后期运维带来非常大的好处；
2）路由、负载可以通过类似LVS这样的工具或者编码实现软复杂各有好处；
3）服务升、降级分自动与手动，根据实际访问情况进行动态调整；
4）服务监测、依赖关系尽量做到自动化；
5）监控、统计一定要自动化，并且能够进行细粒度分析；

关于SOA的发布，有两点不得不提一下，那就是自动化发布与灰度发布。自动化发布会大幅度减小由于业务复杂性和技术复杂性带来的问题，同时把人从机械化的操作中解放出来从而完成更重要的功能、方案改进等工作；灰度发布在SOA架构中的作用尤为重要，当我们发布一个新功能或有者针对某地区（或人群）的活动时，就会用到灰度发布。