Web服务架构之路--开篇

离开腾讯后，出来开始所谓的“创业”，开始逐步走向所谓的架构师之路。

仔细想想，其实自己一直都在做一些原创性的设计，但是一直是为自己的企业做的，所以也一直未公开发表过！

~~~~~~~~~~~~~~~~~~~追忆~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. 2011年人人Symbian客户端，信箱数据交互模型(Android也试用）

    手机客户端在操作的过程中，存在大量的网络交互。当时的网络引擎的API设计，是利用callback指针的方式进行。但是客户端交互中存在大量的页面跳转交互，例如当用户在页面回复一个用户后，很有可能跳转到查看详细新鲜事的页面。代码中充斥着register和unregister回调的，以及页面状态的判断。相关BUG也极其的多，代码凌乱，难以编写。不是所有程序员都能很好的编写异步代码的##

1）信箱模型采用mail的形式封住数据，每封mail都有自己的格式，发送地址。

2）每个数据接受者MailHandler都有一个邮箱，当其在线是可以直接处理mail；当其不在线时，mail会依次进行       post。

3）每封mail，投递到中间转发组件（PostOffice), 会按照协议类型（http, file, image)等等，被数据存进行接管。

4）处理完成后投递会PostOffice，按照mail的收件地址，进行转发。每个MailHandler会自动生成其收件地址，也可以重写为固定地址（适用于单例）

5）MailHandler的状态维护，大多数采用UI框架的hide事件设置为离线状态，show事件为在线状态

6）Symbian的视图切换框架被我改写为和Android相似的Activity间的切换框架

期间数据交互，不存在任何的指针引用。数据会被自动缓存，无用数据会被自动丢弃（适用于取消，但是实际已请求的情况）。随机崩溃的bug减少很多。

2. Symbian崩溃保留

http://wangli-whu.blog.163.com/blog/static/115098317201252894356156/

3. 2011至2012年期间，后台开发

    一直在学习，我的web服务架构，基本都是从这里学过来的。只不过腾讯采用C++的平台，我没有带出任何源代码。

    我希望构建一个以java为主的平台，并且从细节上改变以前一些不合理不好用的地方。我现在的架构也是根据电商平台的架构，一步一步的进行的。

4. 2012年2014年期间，Chromium内核预研，基于闭包的消息系统

   chromium内核逐步脱离webkit，google团队开发自己的blink的内核。我们希望在Android版本上构建一套基于blink内核的单进程架构的内核版本。chromium的content自身具备多进程架构，但是放在Android版本上，多进程版本显得过于厚重。

   chromium内核中提供了PostTask的接口，但是类之间还是存在指针引用和线程应用。我希望面向功能的类能封闭在，通过消息来改变自身状态提供功能。从而构建一套面向对象，解耦，线程安全的系统。帮团队成员从繁杂的多线程编程中解放出来。

   我们开发好了基础版本后，进行迭代测试。老同事说，感觉我们随机崩溃的bug好少呀！，这是我设想的目的。

好了，回归正题。我们的目标是海量服务Web框架，先上图

                    

这样一套架构图，乍看起来没啥大不了。大部分大型Web服务都会这么做。这是典型的SOA系统！

1. 创业公司是否需要做这样的一个框架？

    确实，直接Web到DB的配置是最简单不过的，随便拿一个在培训学习培训过几天的人都能写。这样初期成本是很低，但是每个公司是求发展的。

    团队协作带来的成本，后续高负载引发系统不可用带来的间接损失，其实是非常大的。

2. 采用SOA后生产力会变低吗？

    SOA的系统强调接口设计，每个AO和DAO之间都用IDL来约束。相反，从某种程度更加加强了接口设计，可复用性也得到了极大的提高。模块化的工作对于业务系统来讲，是一个至关重要的工作。

3. 平台框架需要做什么?

       1) 提供各种组件，简化业务需求的使用方式。(其实和现在的云服务很类似)

    2) 配置能够集中管理，检验。避免发布期的错误，便于升级，扩容和维护

    3) 多机负载，自动路由，尽量避免单点故障

    4) 监控体系，及时发现和定位问题。

    5) 易于发布和运维，提供自动化方案

4. 难在那里？

    难在细节，难在易用性，难在稳定性，难在高性能！

下一篇开始介绍RPC服务平台的构建，也是我最重要的组件svr_platform