微服务随着自动化运维等相关技术的生长，微服务变得更容易治理，这给了微服务架构良好的生长时机；同时，Docker 等容器技术的生长，使微服务架构的落地变得越发利便，这更是为其成为主流技术铺好了门路。现在各家对微服务架构都有自己的明白与落地实践。

本次 InfoQ 采访到 58 抵家技术委员会主席沈剑老师，请他讲讲他对微服务架构的一些思考。沈剑老师之前任职于 58 抵家，现在在 58 速运，本次分享涉及到 58 抵家与 58 速运的相关内容。本文即由采访整理而成。本次分享主要从服务化的角度来看待微服务，主要是梳理一下微服务这个观点，不做深入地解说。

从服务化的角度看微服务互联网架构生长的历程中，当业务庞大度剧增，数据量剧增，吞吐量剧增的时候，就会泛起一些技术痛点，下边几个都是最常见的：痛点一：代码随处拷贝举一个最常见的业务的例子：用户数据的会见。绝大部门公司都有一个数据库用来存储用户数据，而各个业务都有会见用户数据的需求。各个业务线都是自己通过 DAO（Data Access Object）写 SQL 会见 user 库来存取用户数据，这无形中就导致了代码的拷贝。抽象出一个服务层之后，有统一的一份代码，那么就解决了代码复用的问题。

同时业务方通过 RPC 会见用户数据，就像挪用一个当地函数一样，好比使用User = UserService::GetUserById(uid);传入一个 uid，获得一个 User 实体，就像挪用当地函数一样，不需要体贴序列化、后端执行、网络传输、反序列化等庞大性，利便高效。痛点二：庞大性扩散这个内容主要讲一下下边两个点： 1、缓存导致的庞大性随着会见量越来越高，数据库成了瓶颈，需要加入缓存来降低数据库的读写压力，于是架构中引入了缓存，由于没有统一的服务层，各个业务线都需要关注缓存的引入导致的庞大性：对于用户数据的写请求，所有业务线都要升级代码：1、先淘汰 cache2、再写数据对于用户数据的读请求，所有业务线也都要升级代码：1、先读 cache，掷中则返回2、没掷中则读数据库3、再把数据放入 cache这个庞大性是典型的“业务无关”的庞大性，业务方需要被迫升级。2、分库分表导致的庞大性数据量越来越大，数据库需要举行水平拆分，于是架构中又引入了分库分表，这时又是由于没有统一的服务层，各个业务线都需要关注分库分表的引入导致的庞大性。

这个庞大性也是典型的“业务无关”的庞大性，业务方需要被迫升级。有了服务层之后，只有服务层需要专注关注底层的庞大性了，向上游屏蔽了细节。痛点三：库的复用与耦合服务化并不是唯一解决上述两个痛点的方法，另一种方法是抽象出统一的“库”。好比抽象出一个 user.so，卖力整个用户数据的存取，从而制止代码的拷贝。

至于庞大性，现在也只剩下 user.so 这一个地方需要关注了。可是这时候会引入新的问题：库的版本维护与业务线之间代码的耦合。好比业务线 A 将 user.so 由版本 1 升级至版本 2，如果不兼容业务线 B 的代码，那就会导致 B 业务泛起问题；业务线 A 如果通知了业务线 B 升级，这时的业务线 B 就会去升级，但这是与它“自身业务无关”的升级。

痛点四：SQL 质量得不到保障，业务相互影响本质上 SQL 语句还是各个业务线拼装的，资深的工程师写出高质量的 SQL 没啥问题，履历没有这么富厚的工程师可能会写出一些低效的 SQL。业务线通过 DAO 会见数据库，如果业务线 A 写了一个全表扫描的 SQL，导致数据库的 CPU100%，影响的不只是这一个业务线，而是 所有的业务线。

有了服务层之后，所有的 SQL 都是服务层提供的，业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话，可以由更资深的工程师维护，而不是像原来 SQL 难以收口，难以控制。痛点五：疯狂的 DB 耦合业务线不只会见 user 数据库，还会联合自己的业务会见自己的数据库。

典型的情况是，通过 join 数据表来实现各自业务线的一些业务逻辑。这样的话，业务线 A 的 table-user 与 table-A 耦合在了一起，业务线 B 的 table-user 与 table-B 耦合在了一起，业务线 C 的 table-user 与 table-C 耦合在了一起，最后的效果就是：table-user，table-A，table-B，table-C 都耦合在了一起。服务化之后，底层的数据库被隔脱离了，可以很利便的拆分出来，举行扩容。

像上边说的，服务层就是在这样的情况下被抽象出来的。归纳综合起来，它就是用来统一完成一部门数据会见或者子业务逻辑。

这就是指服务化。而从这个角度来看，微服务本质上就是指粒度比力细的服务化的实施。详细到 58 抵家 /58 速运就像上边说的，随着业务越来越庞大，数据量越来越大，并发量越来越大，58 抵家因为履历了这些阶段，所以系统架构走上了微服务之路。详细来说，15 年的时候，58 抵家的架构遇到了类似的种种问题：垂直业务扩展，家政、丽人、速运、平台，一些相似的业务代码拷贝越来越严重数据量、并发量提升，底层架构庞大性不停向上游扩散，所有挪用方都需要关注缓存、分库、存储引擎等，效率逐步降低jar 包耦合，多个系统依赖一个公用的 jar 包，一个业务升级导致兼容性问题，影响其他业务数据库耦合，多个业务公用一个数据库，相互耦合，相互影响SQL 质量低，业务相互耦合，一个业务撰写了一个低质量的 SQL，导致其他业务受影响其实我们也不是一开始就直接接纳微服务架构，这个也是经由了差别阶段而演收支来的。

简朴地说，58 抵家刚开始的时候，我们先 找到通用痛点，抽象出通用数据会见与子业务，然后将它们 下沉成微服务。更详细地，早期 58 抵家是抽象出用户中心，订单中心，支付中心等来构建微服务的。我们从 58 速运的角度来讲，刚开始 58 抵家是大一统阶段，就是系统没有举行业务拆分的时候，因为刚开始业务量也小，所以它还是可行的。

厥后整个系统拆分成了站点、数据库、缓存这三个部门。接着我们举行了垂直拆分，将平台、家政、丽人、速运这些业务拆离开来。然后就详细到速运这一块举行服务化架构。

而最近我们还在演进这样一个架构，我们知道速运这一块其实它自己也有多个业务形态，有对小 C 的，有对小 B 的。小 C 是搬迁服务，小 B 是货的服务，大 B 是优配服务。

原来这三块它们都是耦合在一起的，现在也在举行拆分。这其实也就是架构演进历程中一定会泛起的，而详细再讨论下去，其实就是在做一些微服务架构上的事情了。上边这些说的都是业务的垂直拆分，下边看一下我们的系统分层情况是怎么样的。

我们现在的系统分成了四层，如下：第一层：站点平台第二层：业务服务层。把基础数据通用的工具往上抽，就像上边说的，好比它解决代码拷备的痛点，不能让代码拷来拷去，所以把这份代码抽象成一个服务。解决库的耦合，如果之前没有服务化，可能用代码库，用 jar 包、DLL、SO 库来解决代码拷备这个问题，一个库，多个服务依赖，那库的版本升级，影响规模很大，可能多个服务因为一个库的原因耦合在一起。

上边说的这些就是发生在这个层上，它解决的是底层庞大性屏蔽的问题。如果没有服务层，那么 牵一发而动全身。第三层：基础数据服务层。不包罗庞大的业务逻辑，只是数据会见的署理，对数据库层的 CRUD。

原来设计为相对简朴的“DAO 层”。第四层：数据层。数据层包罗缓存和 DB。

最开始的时候是没有业务服务层的，业务应用划分直接会见数据库，导致大量耦合；架构演进到第二个阶段的时候，我们抽象出一些通用的 业务无关 的基础服务，例如地理位置服务、经纬度服务、短网址服务、短信服务等；到了第三个阶段，我们抽象出一些 通用业务 的服务，例如 passport 服务、订单中心服务、支付中心服务等；未来，我们会进一步去抽象更多的通用业务服务。总之，整个微服务架构演进的思路就是：“共性 + 通用痛点”抽象下沉。需要关注的问题许多架构师只看到微服务的利益，但其实微服务会导致增加 系统运维的庞大性，增加 设置文件的庞大性，加大 追盘问题与监控系统的难度。为相识决这些问题，需要有配套的技术体系支撑，例如：引入自动化上线平台解决运维庞大性问题，引入设置中心解决设置耦合的问题，引入监控平台与挪用链平台解决监控与问题追查的问题。

微服务体系，需要有一系列技术基础设施配套，而不只是引入一个简朴的服务框架，而这些配套的技术基础设施，往往比服务框架自己庞大得多。微服务体系配套基础设施包罗可是不限于以下这些工具：设置中心，排除系统之间因为设置文件导致的耦合，做逻辑上解耦（但物理上仍然保持上下游毗连）消息中心，排除系统之间挪用关系导致的耦合，做逻辑上与物理上的双重解耦（物理上不再相互毗连）监控中心，立体化监控，实施机械、历程、接口、日志、用户层面多维度监控，及早发现问题挪用链跟踪系统，图形化，量化展现请求在系统中的挪用路径，及早定位问题 一个重要的原则像上边提到的，在微服务架构的实施历程中，抓住“共性”与“通用痛点”下沉，是一个最常见的原则。这里简朴地再以 58 抵家为例做一下总结。家政、丽人、速运各个业务都有自己的账户体系、订单体系、支付体系，这样成本显然是较高的，庞大性成本也是会不停增加的。

对于这样的一些通用业务，就应该抽象出 passport 服务统一解决 SSO（Single Sign-On）问题；抽象出订单中心服务解决订单的集中存储与展现问题；抽象出支付中心服务来统一解决微信与支付宝的对接，统一解决对账等问题。寄 语关注业务比研究架构更重要，任何脱离业务的架构设计都是耍流氓。找痛点、解决痛点比高瞻远瞩重要，架构是演进而来的，而不是设计而来的。几点小我私家浅见，共勉。

Java工程化、高性能及漫衍式、高性能、深入浅出。高架构。性能调优、Spring，MyBatis，Netty源码分析和大数据等多个知识点。如果你想拿高薪的，想学习的，想就业前景好的，想跟别人竞争能取得优势的，想进阿内里试但担忧面试不外的，你都可以来，群号为：647631030注：加群要求1、具有1-5事情履历的，面临现在盛行的技术不知从何下手，需要突破技术瓶颈的可以加。

2、在公司待久了，过得很清闲，但跳槽时面试碰钉子。需要在短时间内学习、跳槽拿高薪的可以加。

3、如果没有事情履历，但基础很是扎实，对java事情机制，常用设计思想，常用java开发框架掌握熟练的，可以加。4、以为自己很牛B，一般需求都能搞定。可是所学的知识点没有系统化，很难在技术领域继续突破的可以加。

5.阿里Java高级大牛直播解说知识点，分享知识，多年事情履历的梳理和总结，带着大家全面、科学地建设自己的技术体系和技术认知！6.小号或者小白之类加群一律不给过，谢谢。

本文来源：beat365在线登录-www.52zfc.com