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

首先要完成业务拆分、服务规划，前期规划的好，后期的开发、维护成本能降低很多。同时也要考虑到未来业务变化，尽管我们不能预计到可能会发生哪些变化，但是我们可以从架构设计上尽量做到灵活、适应能力强，能够再最短的时间内根据业务变换完成服务新增或调整。

在切换前，要完成整体技术方案的论证、实验、测试，尤其在压力测试和长时间运行测试上要有相对准确的结果，这样才能保证在替换上线后能后更好的运行。

在准备过程中，要尤其要关注灰度发布，切换过程及版本升级都会涉及到。

• 非业务服务切换

  之所以选择非业务服务首先进行切换，是因为此类服务一般是类似短信、邮件、消息队列、缓存等纯技术组件，相对较稳定同时也比较容易为基数人员所控制。

待此类业务替换运行一段时间后，需要对阶段运行结果进行总结，切换过程是否有需要优化的和今后借鉴的？试运行期间遇到了哪些问题、哪些问题是可以提前解决的？服务拆分是否合适、是否易于部署、升级、运维？

• 非核心业务服务切换

接下来要切换的事非核心业务服务，这类服务的重要性没那么高，在切换时，既要借鉴非业务服务切换的经验、也要为最重要的核心业务服务切换积累经验。

在切换过程中，要注意所有相关功能的可用情况，监控、统计数据的波动，根据实际情况适时进行调整，比如在压力大时，增加服务以应对用户的访问。

非核心业务的切换运行时间要适当拉长，注意观察所有服务的状态、积累运维经验。

• 核心业务服务切换

有了前面的准备，这步的切换过程就会简单很多。需要注意的是这次切换一定要做冗余，确保不出问题。

• 移动服务端与网站服务端的分与合

移动端与网站的功能、展现形式、内容、更新频率、面向用户可能都会有不同，所以在服务化过程中，也要注意一下。因为移动端的特殊性（设备差别、网络环境差 别、多版本共存等），通常会在接入层对请求来源进行分析并根据介入端的不同特点进行不同处理，将差别拦截在这一层。这样做的好处是既能保证移动端的使用也 能使内部服务接口更加稳定。

有了接入层，接下来就是如何保证在多版本、多环境前提下使用者在使用过程中不出问题或者少出问题，这就需要不断的对接入层进行优化与改进。前面也提到 过，层越少越少，我们每增加一层，首先要考虑是否有必要，增加后带来哪些好处、可能产生哪些问题，在评估之后决定是否增加。

流量监控与分流、日志分析与统计、应用监控与调整、版本控制、防攻击都是需要在接入层解决的问题。

作者： moocer 
链接：http://www.imooc.com/article/13263
来源：慕课网
本文原创发布于慕课网 ，转载请注明出处，谢谢合作！