互联网架构为什么要做服务化？.pdfVIP

互联⽹架构为什么要做服务化？ 近期参加⼀些业界的技术⼤会，“微服务架构”的话题⾮常之⽕，也在⼀些场合聊过服 务 架构实践，最近⼏期⽂章期望⽤通俗易懂的语⾔聊聊了个⼈对服务 以及微服务 架构的理解，希望能给⼤伙⼀些启⽰。如果有遗漏，也欢迎⼤家补充。 ⼀、互联⽹⾼可⽤架构，为什么要服务化？ 【服务化之前⾼可⽤架构】 在服务 之前，互联⽹的⾼可⽤架构⼤致是这样⼀个架构： （1）⽤户端是浏览器browser ，APP客户端 （2 ）后端⼊⼜是⾼可⽤的nginx集群，⽤于做反向代理 （3 ）中间核⼼是⾼可⽤的web-server集群，研发⼯程师主要编码⼯作就是在这⼀层 （4 ）后端存储是⾼可⽤的db集群，数据存储在这⼀层 更典型的，web-server层是通过DAO/ORM等技术来访问数据库的。 可以看到，最初都是没有服务层的，此时架构会碰到⼀些什么痛点呢？ 【架构痛点⼀：代码到处 贝】 举⼀个最常见的业务的例⼦-⽤户数据的访问，绝⼤部分公司都有⼀个数据库存储⽤ 户数据，各个业务都有访问⽤户数据的需求： 在有⽤户服务之前，各个业务线都是⾃⼰通过DAO写SQL访问 ser库来存取⽤户数 据，这⽆形中就导致了代码的拷贝。 【架构痛点⼆：复杂性扩散】 随着并发量的越来越⾼，⽤户数据的访问数据库成了瓶颈，需要加⼊缓存来降低数据 库的读压⼒，于是架构中引⼊了缓存，由于没有统⼀的服务层，各个业务线都需要关 注缓存的引⼊导致的复杂性： 对于⽤户数据的写请求，所有业务线都要升级代码： （1）先淘汰cache （2 ）再写数据 对于⽤户数据的读请求，所有业务线也都要升级代码： （1）先读cache ，命中则返回 （2 ）没命中则读数据库 （3 ）再把数据放⼊cache 这个复杂性是典型的“业务⽆关”的复杂性，业务⽅需要被迫升级。 随着数据量的越来越⼤，数据库需要进⾏⽔平拆分，于是架构中又引⼊了分库分表， 由于没有统⼀的服务层，各个业务线都需要关注分库分表的引⼊导致的复杂性： 这个复杂性也是典型的“业务⽆关”的复杂性，业务⽅需要被迫升级。 包括b g的修改，发现⼀个b g ，多个地⽅都需要修改。 【架构痛点三：库的复⽤与耦合】 服务 并不是唯⼀的解决上述两痛点的⽅法，抽象出统⼀的“库”是最先容易想到的解 决： （1）代码拷贝 （2 ）复杂性扩散 的⽅法。抽象出⼀个 ser .so ，负责整个⽤户数据的存取，从⽽避免代码的拷贝。⾄于 复杂性，也只有 ser .so这⼀个地⽅需要关注了。 解决了旧的问题，会引⼊新的问题，库的版本维护与业务线之间代码的耦合： 业务线A将 ser .so 由版本1升级⾄版本2 ，如果不兼容业务线B的代码，会导致B业务出 现问题； 业务线A如果通知了业务线B升级，则是的业务线B会⽆故做⼀些“ ⾃⾝业务⽆关”的升 级，⾮常郁闷。当然，如果各个业务线都是拷贝了⼀份代码则不存在这个问题。 【架构痛点四：SQL质量得不到保障，业务相互影响】 业务线通过DAO访问数据库： 本质上SQL语句还是各个业务线拼装的，资深的⼯程师写出⾼质量的SQL没啥问题， 经验没有这么丰富的⼯程师可能会写出⼀些低效的SQL ，假如业务线A写了⼀个全表 扫描的SQL ，导致数据库的CPU 100% ，影响的不只是⼀个业务线，⽽是所有的业务线 都会受影响。 【架构痛点五：疯狂的DB耦合】 业务线不⾄访问 ser数据，还会结合⾃⼰的业务访问⾃⼰的数据： 典型的，通过join数据表来实现各⾃业务线的⼀些业务逻辑。 这样的话，业务线A的table- ser与table-A耦合在了⼀起，业务线B的table- ser与table-B 耦合在了⼀起，业务线C的table- ser与table-C耦合在了⼀起，结果就是：table- ser ， table-A ，table-B ，table-C都耦合在了⼀起。 随着数据量的越来越⼤，业务线ABC的数据库是⽆法垂直拆分开的，必须使⽤⼀个⼤ 库 （疯了，⼀个⼤库300多个业务表 =_= ）。 【架构痛点六：…】 ⼆、服务化解决什么问题？ 为了解决上⾯的诸多问题，互联⽹⾼可⽤分层架构演进的过程中，引⼊了“服务层” 。 以上⽂中的⽤户业务为例，引⼊了 ser-service ，对业务线响应所⽤⽤户数据的存取。 引⼊服务层有什么好处，解决什么问题呢？ 【好处⼀：调⽤⽅爽】 有服务层之前：业务⽅访问⽤户数据，需要通过DAO