近期参加一些业界的技术大会，“微服务架构”的话题非常之火，也在一些场合聊过服务化架构实践，最近几期文章期望用通俗易懂的语言聊聊了个人对服务化以及微服务架构的理解，希望能给大伙一些启示。如果有遗漏，也欢迎大家补充。一、互联网高可用架构，为什么要服务化？【服务化之前高可用架构】在服务化之前，互联网的高可用架构大致是这样一个架构：（1）用户端是浏览器browser，APP客户端（2）后端入口是高可用的nginx集群，用于做反向代理（3）中间核心是高可用的web-server集群，研发工程师主要编码工作就是在这一层（4）后端存储是高可用的db集群，数据存储在这一层更典型的，web-server层是通过DAO/ORM等技术来访问数据库的。可以看到，最初都是没有服务层的，此时架构会碰到一些什么痛点呢？【架构痛点一：代码到处拷贝】举一个最常见的业务的例子->用户数据的访问，绝大部分公司都有一个数据库存储用户数据，各个业务都有访问用户数据的需求：在有用户服务之前，各个业务线都是自己通过DAO写SQL访问user库来存取用户数据，这无形中就导致了代码的拷贝。【架构痛点二：复杂性扩散】随着并发量的越来越高，用户数据的访问数据库成了瓶颈，需要加入缓存来降低数据库的读压力，于是架构中引入了缓存，由于没有统一的服务层，各个业务线都需要关注缓存的引入导致的复杂性：对于用户数据的写请求，所有业务线都要升级代码：（1）先淘汰cache（2）再写数据对于用户数据的读请求，所有业务线也都要升级代码：（1）先读cache，命中则返回（2）没命中则读数据库（3）再把数据放入cache这个复杂性是典型的“业务无关”的复杂性，业务方需要被迫升级。随着数据量的越来越大，数据库需要进行水平拆分，于是架构中又引入了分库分表，由于没有统一的服务层，各个业务线都需要关注分库分表的引入导致的复杂性：这个复杂性也是典型的“业务无关”的复杂性，业务方需要被迫升级。包括bug的修改，发现一个bug，多个地方都需要修改。【架构痛点三：库的复用与耦合】服务化并不是唯一的解决上述两痛点的方法，抽象出统一的“库”是最先容易想到的解决：（1）代码拷贝（2）复杂性扩散的方法。抽象出一个user.so，负责整个用户数据的存取，从而避免代码的拷贝。至于复杂性，也只有user.so这一个地方需要关注了。解决了旧的问题，会引入新的问题，库的版本维护与业务线之间代码的耦合：业务线A将user.so由版本1升级至版本2，如果不兼容业务线B的代码，会导致B业务...
