13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
微服务架构，是分层架构演进过程中很重要的一环，那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。
创新互联从2013年创立，先为奉新等服务建站，奉新等地企业，进行企业商务咨询服务。为奉新企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
一个业务系统最初的分层架构如上：
此时，web-server层如何获取底层的数据呢?
web-server层获取数据的一段伪代码如上，不用纠结代码的细节，也不用纠结不同编程语言与不同数据库驱动的差异，其获取数据的过程大致为：
如果业务不复杂，这段代码写1次2次还可以，但如果业务越来越复杂，每次都这么获取数据，就略显低效了，有大量冗余、重复、每次必写的代码。
通过技术手段能够实现：
绝大部分公司正在用的ORM，DAO等技术，就是一种分层抽象，可以提高数据获取的效率，屏蔽连接，游标，结果集这些复杂性。
于是，分层架构就演进了。
当手写代码从DB中获取数据，成为通用痛点的时候，就应该分层抽象出DAO层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
抽象出DAO层之后，系统架构并不会一成不变：
于是系统架构变成了这个样子：
业务系统垂直拆分，数据库水平切分，缓存这些都是常见的架构优化手段。
根据楼主的经验，以用户数据为例，流程一般是这样的：
如果业务不复杂，这段代码写1次2次还可以，但如果业务越来越复杂，每次都这么获取数据，就略显低效了，有大量冗余、重复、每次必写的代码。
特别的，业务垂直拆分成非常多的子系统之后：
不相信业务会垂直拆分成多个子系统?举两个例子：
如果每个子系统都需要关注缓存，分库，读写分离的复杂性，调用层会疯掉的。
服务化，数据服务层的抽象势在必行。
通过抽象数据服务层：
于是，分层架构就又演进了。
当业务越来越复杂，垂直拆分的系统越来越多，数据库实施了水平切分，数据层实施了缓存加速之后，底层数据获取复杂性成为通用痛点的时候，就应该抽象出数据服务层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
互联网分层架构是一个很有意思的问题，服务化的引入，并不是越早越好：
千万别鲁莽的在“微服务”大流之下，草率的进行微服务改造，看似“高大上架构”的背后，隐藏着更多并未接触过的“大坑”。还是那句话，架构和业务的特点和阶段有关：一切脱离业务的架构设计，都是耍流氓。
【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】
戳这里，看该作者更多好文
