最近接触了一些技术架构的概念，除了叹服于精美的架构设计思想外，也引发了将技术架构应用于自己应用中的思考。
首先剖析下我们的应用架构。目前我们的应用一直处于一个平稳阶段，针对业务需求快速开发上线，其中并没有太多架构设计。好在QPS不会太高，长时间下来倒没有表现上的问题，但代码维护成本却与日俱增。具体的问题主要集中在代码耦合度非常高，依赖关系强。同一个应用针对不用UI有多套代码，新的业务需求如果要适用于整个应用的话需要再在每个UI中加入相同的判断与处理。长此以往代码体积变得越来越庞大与不可维护。
问题是互通的，既然我们没有走在最前面，那么我们遇到的问题别人一定会遇到，好在这些问题也早就有了非常成熟的解决方案。目前非常流行火热的技术微服务就能很好的解决这个问题。微服务这么火热不仅仅是因为许多大公司再用的原因。微服务通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。而且微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。
说了这么多微服务的优点。那么微服务就没有缺点嘛。和其他技术机构一样，微服务也存在着自己的不足。微服务分布式会带来固有的复杂性。消息传递必须通过网络，开发者需要对每个调用接口做到很好的状态控制。在增加通讯成本的前提下也大大增加了安全风险。虽然现在也有很多成熟的网络通讯解决方案。但这无疑增加了开发者的开发成本。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。另外一般微服务每个服务都会拥有自己的数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。
最后，也许非常多成熟的架构还不能直接应用，可能在结构优化中还有许多路要走，但他们会指引我们方向，使我们快速探索到属于自己的架构。