一、前言
15年10月，怀着憧憬与大干一场的决心，从传统行业转战互联网行业，掰着脚指头一算，快有5个年头；在这5年的光景里，见证了公司业务发展的潮起潮落。
架构从其扮演的角色，我们可以大致分为三块：
1、基础架构：封装第三方的中间件，或者公司自研的基础公共组件，供上层业务系统直接使用；同时提供一些监控手段，方便业务系统定位系统的运行情况，例如接口的调用量，平均响应，超时，失败率等待；
2、应用架构：应用的垂直拆分，应用的边界划分；
3、系统架构：更多的偏向运维层面,devlops运维体系。目前市面上比较火的docker,k8s容器编排。
今天我这里重点聊一下，应用架构、系统架构的演进，有共鸣的，欢迎留言评论；
二、单体架构
15年刚进公司那会，应用刚从单体架构，按照业务线拆分，到处可以看到拆分的影子，代码里面，数据库表到处是别的业务系统的垃圾代码，估计当时为了快速拆分，先复制代码，简单包装一下，新的系统就诞生了，那会可以说是暴力拆分（分家）。
这里讲个笑话，当时我在调试接口的时候，发现用户的请求，为啥进入不了我的系统，为啥？？？？？没有ELK日志，太难分析了。这个时候公司的基础组件的监控绝逼立功了，通过分析服务的提供方，有其他系统在提供，我嚓，原来我的流量，都跑到别人的系统了。也许老铁会问，流量为啥会跑到别人的系统，就是当时业务系统拆分的时候，代码只是copy了一份，别的业务系统还保留了我这业务系统的代码。
赶紧电话过去，通知对方屏蔽代码，下线，下线。。。。。。。。。
单体架构：
大家看一下，在这个架构下面，一个应用实例，就可以满足需求，节约成本，应用和DB都放在一个主机上面；在这个架构下面，运维团队都不需要，研发人员可以自己搞定编译、部署、发布等线上操作；
当研发团队规模慢慢变大时，逐渐发现好多烦恼的问题：
1）XX团队上线，MD还是大白天上线，把系统搞挂了，我们这应用也不能用了，唉，真鄙视这个鸟团队，咋搞的，上线成功率这么低。
2）吊了，好多接口超时，像是数据库挂了，赶紧分析数据库日志，发现某张表，被锁了，MD，谁又在线上DEBUG，找出来，干死他。心里一万个XXXX。
耳朵边隐隐的听到，老板在骂街了，MD，我们又要背锅了，怎么办。。。。。。。
拆分吧，要不迟早被玩死。。。。。一不做二不休，那就干吧。。。。热火朝天的日子就这样的开始了。
三、集群架构
我靠最近咋搞得，流量猛涨，还要加机器，继续拆分，老板此刻不知道该高兴还是郁闷：
愉快的过了几天舒服的日子，不用再公司看吃着夜宵，看着第二天的日出了。老婆孩子，总算不抱怨了。程序猿真不容易，作为顾家的程序猿男人更不容易。
NND，愉快的日子，总是那么短暂，最近公司招聘的DBA找上了门：
看着部门老大为难的表情，感觉又要被老板骂街了，唉。。。。真为他担心。。。。
一会的功夫，部门老大回来了，一脸的笑容，这次老板真豪爽，除了满足这次的机器需求，还给俺们额外加了机器，应对后续发展。我去，真是豪爽。。。。。。。我们得认真干，对得起老板的信任，哈哈。。。。
四、面向SOA架构演进
虽然应用A做了集群部署，但是如果检索模块导致CPU飙升，或者直接OOM，会直接影响当前实例上面的订单交易，导致转化急剧下降，为了解决这些问题，只能硬着头皮继续拆分：
五、SOA向微服务架构演进
经过大刀阔斧的拆分，原有十几个系统，已经逐渐演变成上百个系统，当遇到行业收缩的时候，这简直是个悲剧，运维成本超级高，真所谓合久必分，分久必合。但是对一个架构师来说，应该是五味杂陈。
不可否认，引入容器编排之后，应用部署，水平扩展，特别的方便，效率提升毋庸置疑。
