问题驱动一：“互联网架构为什么要做服务化”问题记录与思考

描述：想写这个系列的原因是，在看完一篇技术文章时，最喜欢的就是翻看下面的评论，有很多人就文章提出的问题和困惑让会让我的思路更宽广，同时能更好的去思考文章或推敲文章所谈的内容，所以决定记录下那些让我觉得很好的评论提问或回复，并以此来重新思考，希望大家可以一起讨论和指正。 ##文章内容回溯 原文链接 这篇文章是58沈剑 在架构师之路系列里写的一篇文章《互联网架构为什么要做服务化》，我在此总结下文章的内容（图片引自原文）： ####一：服务化之前的高可用架构介绍

此时该架构遇到的痛点是： 代码到处拷贝（每个业务线会有一些交叉的业务功能实现），复杂性扩散（比如如果要引入缓存或者分库分表，那么所有业务线都要进行改造），库的复用与耦合（公用的数据库表因业务A需要进行了改造，为了兼容也要通知业务B同步升级），SQL质量得不到保障（所有的业务线人员都要写sql，没有经验的人员会写出慢sql并会影响其他业务线的查询）等等 ###二：服务化解决什么问题？

服务话的出现能够较为合适的解决上述架构带来的问题，比如： 避免了代码的到处拷贝，业务方只需要调用下游服务；复杂性不会扩散，上游业务方不用关注分库分表等底层技术实现；库不在因为join而耦合，一个服务对应一个表；底层服务可以让高级或资深java工程师来负责，避免了一些经验较少的程序员写出质量差的sql

###问题 文章内容总结如上，当然主要还是说服务化解决了什么问题，而不是要盲目的去服务化，每个阶段都有核心问题，服务化随之带来的挑战也是很大的，那么我们基于要解决上面的痛点为前提，不再讨论究竟要不要服务化了，我归纳的评论区问题如下：