国王小组：区块链交易所搭建｜如何用微服务替代单服务架构
本篇文章一共分为三个部分，分别是微服务架构的演进过程、具体实践微服务的应用技术和领域驱动设计的意识转变。微服务架构已经渗透到互联网应用的方方面面，而领域驱动设计也逐渐被业界所接收。
一、微服务架构的演进过程
微服务架构几乎都是从 ALL IN ONE 的单体架构演进而来，中间又经历了分布式架构、面向服务架构的演进过程。
单体架构往往以烟筒式方式发展，往往存在两个主要问题：中心化和耦合度高。所谓中心化，就是数据集中存储在单个数据库中，业务系统集中部署在单台服务器上，通过集群部署方式提供服务能力，然而中心化的问题，也就是单点问题。而耦合度高，主要是指其中一个功能模块升级，其它的模块都得一起升级。这里要说明下，模块依赖度高不是单体架构的错，是因为本来架构可能就没有设计好，但是，在实际场景中，随着快速迭代开发，研发换了一波又一波，产品走了一茬又一茬，难免系统架构腐化严重。
看到了单体架构的诸多问题，系统开始通过按功能或模块进行拆分，拆分成多个独立的子系统，系统间通过 RPC、MQ 方式调用，由此逐渐演变为分布式的服务架构。分布式服务架构主要通过服务化和层次化进行解耦拆分，《架构整洁之道》书中提到一点，系统可以降解为策略和层次，而架构设计就是把相同的策略分到同一个组件中，反之，分属于不同的组件。所以，架构设计可以通过分层设计，由高层次服务调用低层次服务，低层次服务通过接口向上提供服务，以实现系统之间的解耦。也正是在这一阶段，单体架构一下子被拆分成几个或几十个系统。
但是随着架构的发展，问题又接踵而来，在没有做好边界的划分之前，系统拆分的服务往往是松散的。正如《架构整洁之道》所讲：软件架构设计本身就是一门划分边界的艺术。所以，很多系统在这一阶段，又往往进行了服务内聚和去层次化的演变过程。所谓服务内聚，就是以领域驱动设计为原则，重新界定领域边界，对模块进行服务整合，对系统进行合并。而去层次化，则是去除服务层次高低之分，按服务调用最优链路提供服务请求，降低深度，以此保证系统的稳定性能。
二、具体实践微服务的应用技术
系统如何从 0 到 1，从 1 到 2，从 2 到 100，在具体实践微服务的过程并不容易。首先，考虑的第一个问题是：微服务是什么？其实，微服务是一个动作：拆。说到拆，就涉及到两个问题，第一，怎么拆？第二，拆到什么程度。
第一个问题，关于怎么拆，需要关注两个层面，一是发版速度，如商品、交易、促销等不同领域的迭代速度和开发速度是不一致的，所以，应该拆分到不同的领域，否则，就可能耦合在一起，A 上线 B 必须跟着一起上，这可能就应该合并到一起。另一个是能源协同，每个系统后面对应不同的研发团队，一个项目往往需要几个团队分工协作，那么系统拆分必然导致团队协作的成本，所以拆分系统同样也是拆分团队，要考虑协作沟通所带来的成本。
第二个问题，拆到什么程度。其实，已经有很多人对微服务进行了定义，其中我认为最重要的两点：一是微服务或一组微服务，应该是一套独立部署运行的服务，二是微服务所依赖的数据资源应该是彼此间相互独立隔离部署的。
其实，拆只是实践微服务的开始，要搭建整体的微服务框架还要进行四部曲：拆、服务化、高可用、隔离。
1，服务拆分
微服务讲究拆分，那么多微才是微，以及，怎么才是比较合理的拆分。在架构设计领域，有一个大家都在讲的著名定律：康为定律，可以理解为：一个系统架构的组织关系是和团队的组织关系相匹配的。如交易系统会对应一个交易系统的研发团队，商品系统会对应一个商品系统的研发团队，这种职责明确的组织结构会使得系统开发更高效。
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
（图片来自网络）
《未来架构》一书中讲过一个 AKF 立方体模型，从三个纬度讲述功能拆分、水平扩展、数据分区所产生的复杂度，如果只有一个系统，单台部署，单点存储，那么它就应该只是一个点，因为随着量级的增大，系统在每个纬度不断延长，逐渐成为一个庞大的立方体。
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
（图片来自网络）
拆分可以分为系统拆分、功能拆分和读写拆分。如一个单体系统中，按照用户的交互场景看，门户首页可以拆分为前台系统，类目、商品、搜索等功能可以拆分到商品中心，订单、结算、发票等功能则可以拆分到交易中心，这就是简单的系统拆分和功能拆分。而有些功能较为特殊，如商详页，在读取时需要聚合读取，所以又可以进行读写拆分。
2，服务化
微服务首先需要有微服务基础设施，没有微服务基础设施，实践微服务就是一场灾难。以 SOA 落地方式为例，SOA 落地方式主要有：分布式服务化和集中式管理（ESB），分布式服务化的技术手段有 dubbo 或 spring cloud 等等，必须有整套的如服务发现、服务订阅、服务监控、服务追踪、服务日志等微服务基础设置，才能进行微服务架构。不能简单只有 p2p 的服务调用就开始服务化，那是不现实的。
3，服务治理
当服务拆分的设计方案确认完毕，而服务化的基础设施也部署到位，那么系统往往一下子就会突然发布出成百上千个服务接口，就像一个网络一样，每个服务或微服务就像网中的一个节点，彼此之间关联和联系。但是，服务网络应该被设计成为一个有向无环图，否则，就是一团麻。如开始的时候，只是 A 调用 B，但随着业务发展，需要修改，但是因为对 A 不了解，就加个环节 B 调用 A，如此形成了环形调用，不仅逻辑复杂了，还降低了稳定和性能。
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
这里的服务治理不是讲中间件团队的服务治理，如超时优化、启动优化等等，而是作为应用平台对服务的治理。服务治理又分为三个阶段：服务梳理、服务界定和服务编排。所谓服务梳理就是梳理系统对外开放的服务化接口，包括服务的 provider 和 consumer，以及服务分组、动态路由等依赖的梳理，然后对拆散的服务进行归类、界定，确定服务领域从属性，依据领域模型重新界定服务边界，最后通过服务迁移、切换，对同一领域的服务接口进行服务整合，提供统一的服务出口，实现服务编排。
为什么要进行服务治理？那先来看看不进行服务治理的坏处。
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
微服务化拆分必然会在初期产生代码到处拷贝，没有一套代码，必然会造成复杂的扩散，如同样语意的 A、B 两个接口，如果 A 接口存在性能问题需要加缓存，那么 B 接口也会存在同样的问题，并需要同样的改造，这样复杂度就会到处蔓延，同时也无法实现统一的服务层架构，还有，如果同样语意或相似语意的接口太多，那么接口就是混乱的，无法实现有限接口的治理，如果系统出了问题，可能很难定位问题。业务逻辑是依赖于数据的，如果接口是混乱的，那么慢 SQL 等质量差的 SQL 就无法进行有效收口改造，同样就更加难以实现数据库拆分和解耦。综上，服务治理的过程就是从无序到有序的过程。
总结一下看从拆分到服务化的过程，就是将原来一个整体的服务打碎，碎成一块一块的零碎服务，然后再对服务重新归类、整合，形成一个一个新领域的、独立的服务。如单体架构就像一个宏伟的城堡，如果相对其中一个点进行调整和改造，那么可能面临着牵一发而动全身的风险，
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
微服务化就是以一系列小的服务去支撑一个应用的方法论。简明扼要的说，就是：分而治之。
4，服务高可用
服务拆分并服务化之后，是不是就完事了，不！真正的微服务实践才刚刚开始，简单提供了一个接口，是没有意义的，它必须具备高可用、高性能、高并发的三高特性，尤以高可用最为重要。保障服务高可用的方法有很多，如数据异构、多级缓存、超时与重试、熔断、异步并发、降级、限流、消息队列、压测与预案等。
京东T4架构师详细解读微服务架构与领域驱动设计应用实践
重点说下数据异构，所谓数据异构，就是将通过顺序消费或并发消费的方式，订阅 MySQL 数据库的 binlog，然后通过消息，如 Kafka 等 MQ 方式，异地存储到缓存或其它数据源中，如 Redis、Elasticsearch 等。数据异构现在被普通使用，实现数据聚合，形成数据闭环。
在进行数据异构的过程中，需要关注几个关键点，一是 CAP 原则，即强一致性往往被舍弃，而采用最终一致性的设计。二是缓存，缓存在微服务架构中，不能被当成银弹来使用，使用缓存必须正视的问题有：热点缓存 & 大 Value 缓存、缓存穿透等问题。三是消息，消息现在还存在的问题有：延迟问题、消息的不稳定性（如丢消息）、消息的不确定性（如 timeout）、消息补偿、柔性事务等问题。而这些是微服务高可用架构实践中，不能不面对的问题。
交易所APP开发功能
交易所系统开发
交易所系统源码平台
Uniswap交易所开发稳定版
Uniswap交易所系统开发（开发模板）
Uniswap交易所系统源码案例部署
交易所系统开发（成熟及案例）
交易所开发详情源码
交易所系统开发（海外版）
交易所系统开发（多语言）
交易所开发源码版
