从传统软件公司跑出来已经一年有余，10多年的基础平台研发和知识积累，让转型互联网架构和开发感觉没想象中的难，可能是逼格太低，亦或者公司的业务量还没到爆发的时间。但是不管怎么说，能有一次从头搭建互联网应用的机会是可遇不可求的。多少人挤破了头跳槽BAT，而偶却不羡慕。不管结果如何，先结合公司业务和互联网技术，把基础架构和发展方向确定了、夯实了。
网上有很多文章都在讲互联网技术发展的几个阶段和对应的架构： LAMP、服务化、数据库Sharding，只要是了解一点互联网技术知识的通知都清楚。我来公司后，看到的系统结构是这样的。看上去很厉害，有如此多的API站点和服务。但是细细了解却发现：
1.服务层的9个服务，全部是一个一个windows service，并且全部是一行行代码硬撸出来的，每个服务的代码都不一样，稳定性很差。不过还好，有个管理工具勉强进行状态管理。
2.API层基本是每个功能一个站点，但是仅部署在2台服务器上，只能说很超前的结构。所有的API站点也是一个一个硬硬写出来的。
3.API与后台服务是通过thrift通讯的。一开始采用的是短连接，各种不稳定和宕机，后来改成长连接，还是各种不稳定。后来改成了补偿机制基本解决了。但是还是建议大家不要使用windows版本的thrift，各种坑。
4.UI层除App外，是asp.net MVC结构。在互联网公司中，用asp.net MVC真的不多，但是考虑到技术人员的知识体系，我们义无反馈的扛起了这面大旗。
数据库层面的结构更直接，Base、业务，两个数据库，base库是基础数据，通过发布订阅同步到业务库中。业务量不大。
通过上面的情况，可以看到设计者的初衷是好的，本想通过一个松散的部署结构来支撑后续业务的水平扩展，但是缺乏统一的框架支持，存在太多太多的问题。先不说结构是否合理，如此多的部署节点，制作补丁、更新补丁就需要消耗巨大的工作量，一个功能的上线非常非常复杂，而且极其容易出现发布问题。
另外，整个集群有几十台机器，每天夜里睡着觉，突然会被电话吵醒：XXX充不上电了。尼玛，缺少最基本、最重要的监控。所有系统、集群、程序的运行全部是黑盒子，关键是出问题了你还不知道，要等到客户给你反馈。太崩溃了，经历过几个晚上，简直要疯掉的节奏。那段时间有太多的问候。。。
经过一段时间的了解和总结，最终确定系统的架构如下：
1.UI层继续延续现有的结构，后续逐渐向前后端分离发展，逐渐引入H5，替代asp.net MVC
2.API层提供统一开发平台Service Gateway。通过此平台统一对外提供服务，并规范服务的开发、管理。并进行安全控制和访问控制。
3.后台服务提供微服务、分布式服务平台，整合现有的后台服务。提供服务的统一管理和发布部署，后续实现服务治理。
4.提供监控预警平台，从UI、API、Service、基础设施多层对系统进行360度无死角监控和预警。与Service Gateway、服务框架对接，实现服务端的全链路监控和数据联查。
5.搭建配置中心，把所有系统监控配置进行集中管理，降低管理配置项带来的负载性。
6.搭建消息应用中心，提供定时任务、异步任务处理等功能。
7.另外，搭建一套补丁平台，对系统的补丁进行集中管理，并实现自动部署安装的功能。
大体的架子和规划有了，后续再详细介绍每一块的落地方案。
vl 2016-9-18