jiankangbeijing_个人页

从应用工程的生命周期来看，一个应用最大的成本是应用的总维护成本，所以代码的可维护性代表了最终成本，从长远来看统一数据访问模块的抽取可能会减少这种成本。 统一数据访问模块的抽取可以从以下几个方面提高应用系统的设计质量。 一、可维护性 当依赖变化时，有多少代码需要随之改变，如果不实现统一数据访问模块那么业务代码中势必要直接依赖数据实现类DAO，会形成事务脚本类的代码，而这种代码很难维护主要是因为以下几点： 1. 数据结构的不稳定性：DAO操作的是一个纯数据结构的类，这种类映射了数据库中的一个表。数据库的表结构和设计是应用的外部依赖，这种外部依赖随着时间的变化可能会改变，尤其是存储中间件的变更最为常见，例如MySQL变更MongoDB，又或者换一个表设计什么的。 2. 依赖库的升级：DAO类本身可能依赖MyBatis的实现，如果MyBatis未来升级版本，可能会造成用法的不同。同样的，如果未来换一个ORM体系，迁移成本也是巨大的。 二、可扩展性 做新需求或改逻辑时，需要新增或修改多少代码。如果不抽取统一数据访问模块，新需求的增加可能会直接修改业务代码或是直接修改DAO的实现，最终可能会造成大量的if-else语句，造成bug。 三、可测试性 当业务代码中强依赖了数据库等外部依赖之后，想要完整跑通一个测试用例需要确保所有依赖都能跑起来，这个在项目早期是及其困难的。在项目后期也会由于各种系统的不稳定性而导致测试无法通过。 从软件设计角度考虑，一个应用的设计是否合理，主要考查几个设计原则，统一数据访问模块的抽取可以满足这几个设计原则，从而实现高可用、高可扩展、高健壮的应用系统。 1. 单一性原则：单一性原则要求一个对象/类应该只有一个变更的原因。提问者的统一数据访问模块实际上就是实现这个原则，避免因为数据存储方式的变更或是其它数据处理中间件的变更的改变而改变。 2. 依赖反转原则：依赖反转原则要求在代码中依赖抽象，而不是具体的实现。提问者的统一数据访问模块就像是一个共享数据访问层，将具体的数据处理屏蔽在该层后面，让应用依赖统一数据访问这个抽象层。 3. 开闭原则：开放封闭原则指开放扩展，但是封闭修改。提问者的统一数据访问模块的建立可以实现在新增需求时只增加新的实现类，做到尽量不修改原有逻辑，对外部调用者透明。

《微服务治理技术白皮书》是一本基于阿里云生态，全面阐述微服务的开发、测试、生产等不同阶段如何治理的经典之作，对于使用阿里云生态搭建系统的公司来说有很大的学习价值，使用价值。当然对于没有使用阿里云生态但基于阿里开源中间件搭建系统的公司也同样具有相当大的价值，本书的经典是将服务治理分开不同的阶段来阐述，这对于广大开发人员来说可能有些惊讶，大家平时关心的都是生产时的服务治理，结果发现在开发、测试阶段其实也要做服务治理，这在大部分的公司可能都想不到或是做不全，本书不但讲解了为什么要做服务治理，同时也将阿里的最佳实践分享给大家，当然这本书的前提是基于阿里云生态，开发、测试、生产的服务治理自然是使用阿里云的生态做最合理，但是这些方案都可以借鉴到那些不使用阿里云生态的的企业。我就是这样的企业，虽然我们也在开发、测试、生产三个阶段都做了服务治理，但是从全面性和最佳实践上做的并不是最优的，读了这本书后，我发现对我们最大帮助的是运行态的方案，阿里云的方案结合最新的Dubbo实现特别的合适，因此我们也快速完成了Dubbo的升级利用新版本的路由标签改造了无损上下线的治理、灰度发布的治理，目前系统运行良好，采用了新的Dubbo后比我们之前自己做patch的那个版本更好。 真心觉得这本说是阿里云的良心输出。

我们先讨论一下为什么要拆分？ 一般需要拆分的系统有几种： 1）烟囱系统（单体系统） 2）多个业务耦合在一起的复杂系统 3）过程编程为主的业务系统 系统建设发展的最终目的是要为企业降本增效，所以企业需要的是可扩展、可维护的系统架构，这些系统都有一个共同的特点就是随着业务发展系统难以维护、难以扩展、难以快速响应需求等，所以需要更合理的架构，更合理的架构是什么？ DDD与微服务就可以大展身手了，拆分就是核心，那三种系统的具体弊端就不赘述了，但是拆分的最大好处就是可以将系统实现成低耦合、高内聚的系统架构，低耦合、高内聚的优势就是利于扩展，无论是需求响应、系统可用性、系统性能等哪个角度都可以轻松满足。 那么拆分又该按照什么维度去进行呢？ 进行拆分应该按照以下两个领域来进行。 1、业务领域，主要是确定不同的领域模型，这个拆分主要是垂直的。 2、架构领域，主要是具体的系统实现，这个拆分分为垂直、水平两种。 业务领域主要采用DDD来实现，电商典型的有用户、商品、交易、物流、售后领域。 架构领域也就是系统拆分主要由微服务架构来实现，例如用户系统拆分为注册系统、登录系统、查询系统等。 系统拆分按照资源分类 1、应用拆分 2、数据拆分 3、部署拆分 系统拆分光进行应用的拆分是不彻底的作用不明显，所以数据存储也要进行拆分，这两项都进行了，但是部署如果不拆分也不完整，必须将系统按1实例1虚拟机来拆分部署。 系统拆分按照架构分类 1、垂直拆分，按照业务功能拆分，这个最不好把握，DDD可以起到。 2、水平拆分，水平好理解按照层次，这个一般大家都接触的比较多，三层架构、四层架构。 垂直拆分我们一般遵循的规则大致有一下几种： 1）核心业务原子拆分 2）高请求、高并发业务原子拆分 3）低请求、低并发业务聚合拆分

从两个角度思考这个问题 1、业务角度，一个公司垂直有多个业务，并且这多个业务有很多都用到相同的功能和数据，这时一定要将相同的功能和数据抽象出来，形成独立的中心，统一建设，这时中心服务层建设适合使用分布式服务框架(RPC)。典型的有用户中心、商品中心、交易中心等。 2、系统角度，当多个单体业务系统按照垂直拆分后，又根据软件架构需要水平拆分多个层次时，一般在无状态层如果有多个应用提供相同的功能，这时适合将同一层次相同功能的应用形成服务，统一对外提供相同的功能，适合使用分布式服务框架(RPC)。 形成的服务层次都必须要满足提高业务复用及整合，使前端应用能更快速响应多变的市场需求。 使用分布式服务框架(RPC)有以下几个特点： 1. 该层次是无状态层次。 2. 该层次抽象度较高，提供公共共享服务。 3. 该层次服务必须满足高可用、高性能、高并发。