• 关于 工程数据处理怎么看配置 的搜索结果

问题

[精品问答]Java一百问第一期

问问小秘 2019-12-01 21:51:20 791 浏览量 回答数 1

问题

Nginx性能为什么如此吊

小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

问题

程序员报错QA大分享(1)

问问小秘 2020-06-18 15:46:14 8 浏览量 回答数 1

海外云虚拟主机包年25元/月起

海外独享虚拟主机全面上线,助力构建海外网站,提升公司国际形象;全球有效覆盖,超高性价比;建站入门首选,助力出口,适合跨境贸易企业。

问题

dubbo 的 spi 思想是什么?【Java问答学堂】50期

剑曼红尘 2020-07-07 09:48:29 25 浏览量 回答数 1

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

回答

初识 MyBatis MyBatis 是第一个支持自定义 SQL、存储过程和高级映射的类持久框架。MyBatis 消除了大部分 JDBC 的样板代码、手动设置参数以及检索结果。MyBatis 能够支持简单的 XML 和注解配置规则。使 Map 接口和 POJO 类映射到数据库字段和记录。 MyBatis 的特点 那么 MyBatis 具有什么特点呢?或许我们可以从如下几个方面来描述 MyBatis 中的 SQL 语句和主要业务代码分离,我们一般会把 MyBatis 中的 SQL 语句统一放在 XML 配置文件中,便于统一维护。 解除 SQL 与程序代码的耦合,通过提供 DAO 层,将业务逻辑和数据访问逻辑分离,使系统的设计更清晰,更易维护,更易单元测试。SQL 和代码的分离,提高了可维护性。 MyBatis 比较简单和轻量 本身就很小且简单。没有任何第三方依赖,只要通过配置 jar 包,或者如果你使用 Maven 项目的话只需要配置 Maven 以来就可以。易于使用,通过文档和源代码,可以比较完全的掌握它的设计思路和实现。 屏蔽样板代码 MyBatis 回屏蔽原始的 JDBC 样板代码,让你把更多的精力专注于 SQL 的书写和属性-字段映射上。 编写原生 SQL,支持多表关联 MyBatis 最主要的特点就是你可以手动编写 SQL 语句,能够支持多表关联查询。 提供映射标签,支持对象与数据库的 ORM 字段关系映射 ORM 是什么?对象关系映射(Object Relational Mapping,简称ORM) ,是通过使用描述对象和数据库之间映射的元数据,将面向对象语言程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 提供 XML 标签,支持编写动态 SQL。 你可以使用 MyBatis XML 标签,起到 SQL 模版的效果,减少繁杂的 SQL 语句,便于维护。 MyBatis 整体架构 MyBatis 最上面是接口层,接口层就是开发人员在 Mapper 或者是 Dao 接口中的接口定义,是查询、新增、更新还是删除操作;中间层是数据处理层,主要是配置 Mapper -> XML 层级之间的参数映射,SQL 解析,SQL 执行,结果映射的过程。上述两种流程都由基础支持层来提供功能支撑,基础支持层包括连接管理,事务管理,配置加载,缓存处理等。 接口层 在不与Spring 集成的情况下,使用 MyBatis 执行数据库的操作主要如下: InputStream is = Resources.getResourceAsStream("myBatis-config.xml"); SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory factory = builder.build(is); sqlSession = factory.openSession(); 其中的SqlSessionFactory,SqlSession是 MyBatis 接口的核心类,尤其是 SqlSession,这个接口是MyBatis 中最重要的接口,这个接口能够让你执行命令,获取映射,管理事务。 数据处理层 配置解析 在 Mybatis 初始化过程中,会加载 mybatis-config.xml 配置文件、映射配置文件以及 Mapper 接口中的注解信息,解析后的配置信息会形成相应的对象并保存到 Configration 对象中。之后,根据该对象创建SqlSessionFactory 对象。待 Mybatis 初始化完成后,可以通过 SqlSessionFactory 创建 SqlSession 对象并开始数据库操作。 SQL 解析与 scripting 模块 Mybatis 实现的动态 SQL 语句,几乎可以编写出所有满足需要的 SQL。 Mybatis 中 scripting 模块会根据用户传入的参数,解析映射文件中定义的动态 SQL 节点,形成数据库能执行的SQL 语句。 SQL 执行 SQL 语句的执行涉及多个组件,包括 MyBatis 的四大核心,它们是: Executor、StatementHandler、ParameterHandler、ResultSetHandler。SQL 的执行过程可以用下面这幅图来表示 MyBatis 层级结构各个组件的介绍(这里只是简单介绍,具体介绍在后面): SqlSession: ,它是 MyBatis 核心 API,主要用来执行命令,获取映射,管理事务。接收开发人员提供 Statement Id 和参数。并返回操作结果。Executor :执行器,是 MyBatis 调度的核心,负责 SQL 语句的生成以及查询缓存的维护。StatementHandler : 封装了JDBC Statement 操作,负责对 JDBC Statement 的操作,如设置参数、将Statement 结果集转换成 List 集合。ParameterHandler : 负责对用户传递的参数转换成 JDBC Statement 所需要的参数。ResultSetHandler : 负责将 JDBC 返回的 ResultSet 结果集对象转换成 List 类型的集合。TypeHandler : 用于 Java 类型和 JDBC 类型之间的转换。MappedStatement : 动态 SQL 的封装SqlSource : 表示从 XML 文件或注释读取的映射语句的内容,它创建将从用户接收的输入参数传递给数据库的 SQL。Configuration: MyBatis 所有的配置信息都维持在 Configuration 对象之中。 基础支持层 反射模块 Mybatis 中的反射模块,对 Java 反射进行了很好的封装,提供了简易的 API,方便上层调用,并且对反射操作进行了一系列的优化,比如,缓存了类的 元数据(MetaClass)和对象的元数据(MetaObject),提高了反射操作的性能。 类型转换模块 Mybatis 的别名机制,能够简化配置文件,该机制是类型转换模块的主要功能之一。类型转换模块的另一个功能是实现 JDBC 类型与 Java 类型的转换。在 SQL 语句绑定参数时,会将数据由 Java 类型转换成 JDBC 类型;在映射结果集时,会将数据由 JDBC 类型转换成 Java 类型。 日志模块 在 Java 中,有很多优秀的日志框架,如 Log4j、Log4j2、slf4j 等。Mybatis 除了提供了详细的日志输出信息,还能够集成多种日志框架,其日志模块的主要功能就是集成第三方日志框架。 资源加载模块 该模块主要封装了类加载器,确定了类加载器的使用顺序,并提供了加载类文件和其它资源文件的功能。 解析器模块 该模块有两个主要功能:一个是封装了 XPath,为 Mybatis 初始化时解析 mybatis-config.xml配置文件以及映射配置文件提供支持;另一个为处理动态 SQL 语句中的占位符提供支持。 数据源模块 Mybatis 自身提供了相应的数据源实现,也提供了与第三方数据源集成的接口。数据源是开发中的常用组件之一,很多开源的数据源都提供了丰富的功能,如连接池、检测连接状态等,选择性能优秀的数据源组件,对于提供ORM 框架以及整个应用的性能都是非常重要的。 事务管理模块 一般地,Mybatis 与 Spring 框架集成,由 Spring 框架管理事务。但 Mybatis 自身对数据库事务进行了抽象,提供了相应的事务接口和简单实现。 缓存模块 Mybatis 中有一级缓存和二级缓存,这两级缓存都依赖于缓存模块中的实现。但是需要注意,这两级缓存与Mybatis 以及整个应用是运行在同一个 JVM 中的,共享同一块内存,如果这两级缓存中的数据量较大,则可能影响系统中其它功能,所以需要缓存大量数据时,优先考虑使用 Redis、Memcache 等缓存产品。 Binding 模块 在调用 SqlSession 相应方法执行数据库操作时,需要制定映射文件中定义的 SQL 节点,如果 SQL 中出现了拼写错误,那就只能在运行时才能发现。为了能尽早发现这种错误,Mybatis 通过 Binding 模块将用户自定义的Mapper 接口与映射文件关联起来,系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作,从而避免上述问题。注意,在开发中,我们只是创建了 Mapper 接口,而并没有编写实现类,这是因为 Mybatis 自动为 Mapper 接口创建了动态代理对象。 MyBatis 核心组件 在认识了 MyBatis 并了解其基础架构之后,下面我们来看一下 MyBatis 的核心组件,就是这些组件实现了从 SQL 语句到映射到 JDBC 再到数据库字段之间的转换,执行 SQL 语句并输出结果集。首先来认识 MyBatis 的第一个核心组件 SqlSessionFactory 对于任何框架而言,在使用该框架之前都要经历过一系列的初始化流程,MyBatis 也不例外。MyBatis 的初始化流程如下 String resource = "org/mybatis/example/mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(resource); SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); sqlSessionFactory.openSession(); 上述流程中比较重要的一个对象就是SqlSessionFactory,SqlSessionFactory 是 MyBatis 框架中的一个接口,它主要负责的是 MyBatis 框架初始化操作 为开发人员提供SqlSession 对象 SqlSessionFactory 有两个实现类,一个是 SqlSessionManager 类,一个是 DefaultSqlSessionFactory 类 DefaultSqlSessionFactory : SqlSessionFactory 的默认实现类,是真正生产会话的工厂类,这个类的实例的生命周期是全局的,它只会在首次调用时生成一个实例(单例模式),就一直存在直到服务器关闭。 SqlSessionManager : 已被废弃,原因大概是: SqlSessionManager 中需要维护一个自己的线程池,而使用MyBatis 更多的是要与 Spring 进行集成,并不会单独使用,所以维护自己的 ThreadLocal 并没有什么意义,所以 SqlSessionManager 已经不再使用。 ####SqlSessionFactory 的执行流程 下面来对 SqlSessionFactory 的执行流程来做一个分析 首先第一步是 SqlSessionFactory 的创建 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); 1 从这行代码入手,首先创建了一个 SqlSessionFactoryBuilder 工厂,这是一个建造者模式的设计思想,由 builder 建造者来创建 SqlSessionFactory 工厂 然后调用 SqlSessionFactoryBuilder 中的 build 方法传递一个InputStream 输入流,Inputstream 输入流中就是你传过来的配置文件 mybatis-config.xml,SqlSessionFactoryBuilder 根据传入的 InputStream 输入流和environment、properties属性创建一个XMLConfigBuilder对象。SqlSessionFactoryBuilder 对象调用XMLConfigBuilder 的parse()方法,流程如下。 XMLConfigBuilder 会解析/configuration标签,configuration 是 MyBatis 中最重要的一个标签,下面流程会介绍 Configuration 标签。 MyBatis 默认使用 XPath 来解析标签,关于 XPath 的使用,参见 https://www.w3school.com.cn/xpath/index.asp 在 parseConfiguration 方法中,会对各个在 /configuration 中的标签进行解析 重要配置 说一下这些标签都是什么意思吧 properties,外部属性,这些属性都是可外部配置且可动态替换的,既可以在典型的 Java 属性文件中配置,亦可通过 properties 元素的子元素来传递。 <properties> <property name="driver" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/test" /> <property name="username" value="root" /> <property name="password" value="root" /> </properties> 一般用来给 environment 标签中的 dataSource 赋值 <environment id="development"> <transactionManager type="JDBC" /> <dataSource type="POOLED"> <property name="driver" value="${driver}" /> <property name="url" value="${url}" /> <property name="username" value="${username}" /> <property name="password" value="${password}" /> </dataSource> </environment> 还可以通过外部属性进行配置,但是我们这篇文章以原理为主,不会介绍太多应用层面的操作。 settings ,MyBatis 中极其重要的配置,它们会改变 MyBatis 的运行时行为。 settings 中配置有很多,具体可以参考 https://mybatis.org/mybatis-3/zh/configuration.html#settings 详细了解。这里介绍几个平常使用过程中比较重要的配置 一般使用如下配置 <settings> <setting name="cacheEnabled" value="true"/> <setting name="lazyLoadingEnabled" value="true"/> </settings> typeAliases,类型别名,类型别名是为 Java 类型设置的一个名字。 它只和 XML 配置有关。 <typeAliases> <typeAlias alias="Blog" type="domain.blog.Blog"/> </typeAliases> 当这样配置时,Blog 可以用在任何使用 domain.blog.Blog 的地方。 typeHandlers,类型处理器,无论是 MyBatis 在预处理语句(PreparedStatement)中设置一个参数时,还是从结果集中取出一个值时, 都会用类型处理器将获取的值以合适的方式转换成 Java 类型。 在 org.apache.ibatis.type 包下有很多已经实现好的 TypeHandler,可以参考如下 你可以重写类型处理器或创建你自己的类型处理器来处理不支持的或非标准的类型。 具体做法为:实现 org.apache.ibatis.type.TypeHandler 接口, 或继承一个很方便的类 org.apache.ibatis.type.BaseTypeHandler, 然后可以选择性地将它映射到一个 JDBC 类型。 objectFactory,对象工厂,MyBatis 每次创建结果对象的新实例时,它都会使用一个对象工厂(ObjectFactory)实例来完成。默认的对象工厂需要做的仅仅是实例化目标类,要么通过默认构造方法,要么在参数映射存在的时候通过参数构造方法来实例化。如果想覆盖对象工厂的默认行为,则可以通过创建自己的对象工厂来实现。 public class ExampleObjectFactory extends DefaultObjectFactory { public Object create(Class type) { return super.create(type); } public Object create(Class type, List constructorArgTypes, List constructorArgs) { return super.create(type, constructorArgTypes, constructorArgs); } public void setProperties(Properties properties) { super.setProperties(properties); } public boolean isCollection(Class type) { return Collection.class.isAssignableFrom(type); } } 然后需要在 XML 中配置此对象工厂 <objectFactory type="org.mybatis.example.ExampleObjectFactory"> <property name="someProperty" value="100"/> </objectFactory> plugins,插件开发,插件开发是 MyBatis 设计人员给开发人员留给自行开发的接口,MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。MyBatis 允许使用插件来拦截的方法调用包括:Executor、ParameterHandler、ResultSetHandler、StatementHandler 接口,这几个接口也是 MyBatis 中非常重要的接口,我们下面会详细介绍这几个接口。 environments,MyBatis 环境配置,MyBatis 可以配置成适应多种环境,这种机制有助于将 SQL 映射应用于多种数据库之中。例如,开发、测试和生产环境需要有不同的配置;或者想在具有相同 Schema 的多个生产数据库中 使用相同的 SQL 映射。 这里注意一点,虽然 environments 可以指定多个环境,但是 SqlSessionFactory 只能有一个,为了指定创建哪种环境,只要将它作为可选的参数传递给 SqlSessionFactoryBuilder 即可。 SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment); SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment, properties); databaseIdProvider ,数据库厂商标示,MyBatis 可以根据不同的数据库厂商执行不同的语句,这种多厂商的支持是基于映射语句中的 databaseId 属性。 <databaseIdProvider type="DB_VENDOR"> <property name="SQL Server" value="sqlserver"/> <property name="DB2" value="db2"/> <property name="Oracle" value="oracle" /> </databaseIdProvider> mappers,映射器,这是告诉 MyBatis 去哪里找到这些 SQL 语句,mappers 映射配置有四种方式 上面的一个个属性都对应着一个解析方法,都是使用 XPath 把标签进行解析,解析完成后返回一个 DefaultSqlSessionFactory 对象,它是 SqlSessionFactory 的默认实现类。这就是 SqlSessionFactoryBuilder 的初始化流程,通过流程我们可以看到,初始化流程就是对一个个 /configuration 标签下子标签的解析过程。 SqlSession 在 MyBatis 初始化流程结束,也就是 SqlSessionFactoryBuilder -> SqlSessionFactory 的获取流程后,我们就可以通过 SqlSessionFactory 对象得到 SqlSession 然后执行 SQL 语句了。具体来看一下这个过程‘ 在 SqlSessionFactory.openSession 过程中我们可以看到,会调用到 DefaultSqlSessionFactory 中的 openSessionFromDataSource 方法,这个方法主要创建了两个与我们分析执行流程重要的对象,一个是 Executor 执行器对象,一个是 SqlSession 对象。执行器我们下面会说,现在来说一下 SqlSession 对象 SqlSession 对象是 MyBatis 中最重要的一个对象,这个接口能够让你执行命令,获取映射,管理事务。SqlSession 中定义了一系列模版方法,让你能够执行简单的 CRUD 操作,也可以通过 getMapper 获取 Mapper 层,执行自定义 SQL 语句,因为 SqlSession 在执行 SQL 语句之前是需要先开启一个会话,涉及到事务操作,所以还会有 commit、 rollback、close 等方法。这也是模版设计模式的一种应用。 MapperProxy MapperProxy 是 Mapper 映射 SQL 语句的关键对象,我们写的 Dao 层或者 Mapper 层都是通过 MapperProxy 来和对应的 SQL 语句进行绑定的。下面我们就来解释一下绑定过程 这就是 MyBatis 的核心绑定流程,我们可以看到 SqlSession 首先调用 getMapper 方法,我们刚才说到 SqlSession 是大哥级别的人物,只定义标准(有一句话是怎么说的来着,一流的企业做标准,二流的企业做品牌,三流的企业做产品)。 SqlSession 不愿意做的事情交给 Configuration 这个手下去做,但是 Configuration 也是有小弟的,它不愿意做的事情直接甩给小弟去做,这个小弟是谁呢?它就是 MapperRegistry,马上就到核心部分了。MapperRegistry 相当于项目经理,项目经理只从大面上把握项目进度,不需要知道手下的小弟是如何工作的,把任务完成了就好。最终真正干活的还是 MapperProxyFactory。看到这段代码 Proxy.newProxyInstance ,你是不是有一种恍然大悟的感觉,如果你没有的话,建议查阅一下动态代理的文章,这里推荐一篇 (https://www.jianshu.com/p/95970b089360) 也就是说,MyBatis 中 Mapper 和 SQL 语句的绑定正是通过动态代理来完成的。 通过动态代理,我们就可以方便的在 Dao 层或者 Mapper 层定义接口,实现自定义的增删改查操作了。那么具体的执行过程是怎么样呢?上面只是绑定过程,别着急,下面就来探讨一下 SQL 语句的执行过程。 MapperProxyFactory 会生成代理对象,这个对象就是 MapperProxy,最终会调用到 mapperMethod.execute 方法,execute 方法比较长,其实逻辑比较简单,就是判断是 插入、更新、删除 还是 查询 语句,其中如果是查询的话,还会判断返回值的类型,我们可以点进去看一下都是怎么设计的。 很多代码其实可以忽略,只看我标出来的重点就好了,我们可以看到,不管你前面经过多少道关卡处理,最终都逃不过 SqlSession 这个老大制定的标准。 我们以 selectList 为例,来看一下下面的执行过程。 这是 DefaultSqlSession 中 selectList 的代码,我们可以看到出现了 executor,这是什么呢?我们下面来解释。 Executor 还记得我们之前的流程中提到了 Executor(执行器) 这个概念吗?我们来回顾一下它第一次出现的位置。 由 Configuration 对象创建了一个 Executor 对象,这个 Executor 是干嘛的呢?下面我们就来认识一下 Executor 的继承结构 每一个 SqlSession 都会拥有一个 Executor 对象,这个对象负责增删改查的具体操作,我们可以简单的将它理解为 JDBC 中 Statement 的封装版。 也可以理解为 SQL 的执行引擎,要干活总得有一个发起人吧,可以把 Executor 理解为发起人的角色。 首先先从 Executor 的继承体系来认识一下 如上图所示,位于继承体系最顶层的是 Executor 执行器,它有两个实现类,分别是BaseExecutor和 CachingExecutor。 BaseExecutor 是一个抽象类,这种通过抽象的实现接口的方式是适配器设计模式之接口适配 的体现,是Executor 的默认实现,实现了大部分 Executor 接口定义的功能,降低了接口实现的难度。BaseExecutor 的子类有三个,分别是 SimpleExecutor、ReuseExecutor 和 BatchExecutor。 SimpleExecutor : 简单执行器,是 MyBatis 中默认使用的执行器,每执行一次 update 或 select,就开启一个Statement 对象,用完就直接关闭 Statement 对象(可以是 Statement 或者是 PreparedStatment 对象) ReuseExecutor : 可重用执行器,这里的重用指的是重复使用 Statement,它会在内部使用一个 Map 把创建的Statement 都缓存起来,每次执行 SQL 命令的时候,都会去判断是否存在基于该 SQL 的 Statement 对象,如果存在 Statement 对象并且对应的 connection 还没有关闭的情况下就继续使用之前的 Statement 对象,并将其缓存起来。因为每一个 SqlSession 都有一个新的 Executor 对象,所以我们缓存在 ReuseExecutor 上的 Statement作用域是同一个 SqlSession。 BatchExecutor : 批处理执行器,用于将多个 SQL 一次性输出到数据库 CachingExecutor: 缓存执行器,先从缓存中查询结果,如果存在就返回之前的结果;如果不存在,再委托给Executor delegate 去数据库中取,delegate 可以是上面任何一个执行器。 Executor 的创建和选择 我们上面提到 Executor 是由 Configuration 创建的,Configuration 会根据执行器的类型创建,如下 这一步就是执行器的创建过程,根据传入的 ExecutorType 类型来判断是哪种执行器,如果不指定 ExecutorType ,默认创建的是简单执行器。它的赋值可以通过两个地方进行赋值: 可以通过 标签来设置当前工程中所有的 SqlSession 对象使用默认的 Executor <settings> <!--取值范围 SIMPLE, REUSE, BATCH --> <setting name="defaultExecutorType" value="SIMPLE"/> </settings> 另外一种直接通过Java对方法赋值的方式 session = factory.openSession(ExecutorType.BATCH); Executor 的具体执行过程 Executor 中的大部分方法的调用链其实是差不多的,下面是深入源码分析执行过程,如果你没有时间或者暂时不想深入研究的话,给你下面的执行流程图作为参考。 我们紧跟着上面的 selectList 继续分析,它会调用到 executor.query 方法。 当有一个查询请求访问的时候,首先会经过 Executor 的实现类 CachingExecutor ,先从缓存中查询 SQL 是否是第一次执行,如果是第一次执行的话,那么就直接执行 SQL 语句,并创建缓存,如果第二次访问相同的 SQL 语句的话,那么就会直接从缓存中提取。 上面这段代码是从 selectList -> 从缓存中 query 的具体过程。可能你看到这里有些觉得类都是什么东西,我想鼓励你一下,把握重点,不用每段代码都看,从找到 SQL 的调用链路,其他代码想看的时候在看,看源码就是很容易发蒙,容易烦躁,但是切记一点,把握重点。 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler StatementHandler 的继承结构 有没有感觉和 Executor 的继承体系很相似呢?最顶级接口是四大组件对象,分别有两个实现类 BaseStatementHandler 和 RoutingStatementHandler,BaseStatementHandler 有三个实现类, 他们分别是 SimpleStatementHandler、PreparedStatementHandler 和 CallableStatementHandler。 RoutingStatementHandler : RoutingStatementHandler 并没有对 Statement 对象进行使用,只是根据StatementType 来创建一个代理,代理的就是对应Handler的三种实现类。在MyBatis工作时,使用的StatementHandler 接口对象实际上就是 RoutingStatementHandler 对象。 BaseStatementHandler : 是 StatementHandler 接口的另一个实现类,它本身是一个抽象类,用于简化StatementHandler 接口实现的难度,属于适配器设计模式体现,它主要有三个实现类 SimpleStatementHandler: 管理 Statement 对象并向数据库中推送不需要预编译的SQL语句。PreparedStatementHandler: 管理 Statement 对象并向数据中推送需要预编译的SQL语句。CallableStatementHandler:管理 Statement 对象并调用数据库中的存储过程。 StatementHandler 的创建和源码分析 我们继续来分析上面 query 的调用链路,StatementHandler 的创建过程如下 MyBatis 会根据 SQL 语句的类型进行对应 StatementHandler 的创建。我们以预处理 StatementHandler 为例来讲解一下 执行器不仅掌管着 StatementHandler 的创建,还掌管着创建 Statement 对象,设置参数等,在创建完 PreparedStatement 之后,我们需要对参数进行处理了。 如 如果用一副图来表示一下这个执行流程的话我想是这样 这里我们先暂停一下,来认识一下第三个核心组件 ParameterHandler ParameterHandler - ParameterHandler 介绍 ParameterHandler 相比于其他的组件就简单很多了,ParameterHandler 译为参数处理器,负责为 PreparedStatement 的 sql 语句参数动态赋值,这个接口很简单只有两个方法 ParameterHandler 只有一个实现类 DefaultParameterHandler , 它实现了这两个方法。 getParameterObject: 用于读取参数setParameters: 用于对 PreparedStatement 的参数赋值ParameterHandler 的解析过程 上面我们讨论过了 ParameterHandler 的创建过程,下面我们继续上面 parameterSize 流程 这就是具体参数的解析过程了,下面我们来描述一下 下面用一个流程图表示一下 ParameterHandler 的解析过程,以简单执行器为例 我们在完成 ParameterHandler 对 SQL 参数的预处理后,回到 SimpleExecutor 中的 doQuery 方法 上面又引出来了一个重要的组件那就是 ResultSetHandler,下面我们来认识一下这个组件 ResultSetHandler - ResultSetHandler 简介 ResultSetHandler 也是一个非常简单的接口 ResultSetHandler 是一个接口,它只有一个默认的实现类,像是 ParameterHandler 一样,它的默认实现类是DefaultResultSetHandler ResultSetHandler 解析过程 MyBatis 只有一个默认的实现类就是 DefaultResultSetHandler,DefaultResultSetHandler 主要负责处理两件事 处理 Statement 执行后产生的结果集,生成结果列表 处理存储过程执行后的输出参数 按照 Mapper 文件中配置的 ResultType 或 ResultMap 来封装成对应的对象,最后将封装的对象返回即可。 其中涉及的主要对象有: ResultSetWrapper : 结果集的包装器,主要针对结果集进行的一层包装,它的主要属性有 ResultSet : Java JDBC ResultSet 接口表示数据库查询的结果。 有关查询的文本显示了如何将查询结果作为java.sql.ResultSet 返回。 然后迭代此ResultSet以检查结果。 TypeHandlerRegistry: 类型注册器,TypeHandlerRegistry 在初始化的时候会把所有的 Java类型和类型转换器进行注册。 ColumnNames: 字段的名称,也就是查询操作需要返回的字段名称 ClassNames: 字段的类型名称,也就是 ColumnNames 每个字段名称的类型 JdbcTypes: JDBC 的类型,也就是 java.sql.Types 类型 ResultMap: 负责处理更复杂的映射关系 在 DefaultResultSetHandler 中处理完结果映射,并把上述结构返回给调用的客户端,从而执行完成一条完整的SQL语句。 内容转载自:CSDN博主:cxuann 原文链接:https://blog.csdn.net/qq_36894974/article/details/104132876?depth_1-utm_source=distribute.pc_feed.none-task&request_id=&utm_source=distribute.pc_feed.none-task

问问小秘 2020-03-05 15:44:27 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 34170 浏览量 回答数 10

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

回答

Layout Go工程项目的整体组织 首先我们看一下整个 Go 工程是怎么组织起来的。 很多同事都在用 GitLab 的,GitLab 的一个 group 里面可以创建很多 project。如果我们进行微服务化改造,以前很多巨石架构的应用可能就拆成了很多个独立的小应用。那么这么多小应用,你是要建 N 个 project 去维护,还是说按照部门或者组来组织这些项目呢?在 B 站的话,我们之前因为是 Monorepo,现在是按照部门去组织管理代码,就是说在单个 GitLab 的 project 里面是有多个 app 的,每一个 app 就表示一个独立的微服务,它可以独立去交付部署。所以说我们看到下面这张图里面,app 的目录里面是有好多个子目录的,比方说我们的评论服务,会员服务。跟 app 同级的目录有一个叫 pkg,可以存放业务有关的公共库。这是我们的一个组织方式。当然,还有一种方式,你可以按照 GitLab 的 project 去组织,但我觉得这样的话可能相对要创建的 project 会非常多。 如果你按部门组织的话,部门里面有很多 app,app 目录怎么去组织?我们实际上会给每一个 app 取一个全局唯一名称,可以理解为有点像 DNS 那个名称。我们对业务的命名也是一样的,我们基本上是三段式的命名,比如账号业务,它是一个账号业务、服务、子服务的三段命名。三段命名以后,在这个 app 目录里面,你也可以按照这三层来组织。比如我们刚刚说的账号目录,我可能就是 account 目录,然后 VIP,在 VIP 目录下可能会放各种各样的不同角色的微服务,比方说可能有一些是做 job,做定时任务或者流式处理的一些任务,有可能是做对外暴露的 API 的一些服务,这个就是我们关于整个大的 app 的组织的一种形式。 微服务中的 app 服务分类 微服务中单个 app 的服务里又分为几类不同的角色。我们基本上会把 app 分为 interface(BFF)、service、job(补充:还有一个 task,偏向定时执行,job 偏向流式) 和 admin。 Interface 是对外的业务网关服务,因为我们最终是面向终端用户的 API,面向 app,面向 PC 场景的,我们把这个叫成业务网关。因为我们不是统一的网关,我们可能是按照大的业务线去独立分拆的一些子网关,这个的话可以作为一个对外暴露的 HTTP 接口的一个目录去组织它的代码,当然也可能是 gRPC 的(参考 B 站对外的 gRPC Moss 分享)。 Service 这个角色主要是面向对内通信的微服务,它不直接对外。也就是说,业务网关的请求会转发或者是会 call 我们的内部的 service,它们之间的通讯可能是使用自己的 RPC,在 b 站我们主要是使用 gRPC。使用 gRPC 通讯以后,service 它因为不直接对外,service 之间可能也可以相互去 call。 Admin 区别于 service,很多应用除了有面向用户的一些接口,实际上还有面向企业内部的一些运营侧的需求,通常数据权限更高,从安全设计角度需要代码物理层面隔离,避免意外。 第四个是 ecode。我们当时也在内部争论了很久,我们的错误码定义到底是放在哪里?我们目前的做法是,一个应用里面,假设你有多种角色,它们可能会复用一些错误码。所以说我们会把我们的 ecode 给单独抽出来,在这一个应用里面是可以复用的。注意,它只在这一个应用里面复用,它不会去跨服跨目录应用,它是针对业务场景的一个业务错误码的组织。 App 目录组织 我们除了一个应用里面多种角色的这种情况,现在展开讲一下具体到一个 service 里面,它到底是怎么组织的。我们的 app 目录下大概会有 api、cmd、configs、 internal 目录,目录里一般还会放置 README、CHANGELOG、OWNERS。 API 是放置 api 定义以及对应的生成的 client 代码,包含基于 pb 定义(我们使用 PB 作为 DSL 描述 API) 生成的 swagger.json。 而 cmd,就是放 main 函数的。Configs 目录主要是放一些服务所需的配置文件,比方说说我们可能会使用 TOML 或者是使用 YAML 文件。 Internal 的话,它里面有四个子目录,分别是 model、dao、service 和 server。Model 的定位职责就是对我们底层存储的持久化层或者存储层的数据的映射,它是具体的 Go 的一个 struct。我们再看 dao,你实际就是要操作 MySQL 或者 Redis,最终返回的就是这些 model(存储映射)。Service 组织起来比较简单,就是我们通过 dao 里面的各个方法来完成一个完整的业务逻辑。我们还看到有个 server,因为我一个微服务有可能企业内部不一定所有 RPC 都统一,那我们处于过渡阶段,所以 server 里面会有两个小目录,一个是 HTTP 目录,暴露的是 HTTP 接口,还有一个是 gRPC 目录,我们会暴露 gRPC 的协议。所以在 server 里面,两个不同的启动的 server,就是说一个服务和启动两个端口,然后去暴露不同的协议,HTTP 接 RPC,它实际上会先 call 到 service,service 再 call 到 dao,dao 实际上会使用 model 的一些数据定义 struct。但这里面有一个非常重要的就是,因为这个结构体不能够直接返回给我们的 api 做外对外暴露来使用,为什么?因为可能从数据库里面取的敏感字段,当我们实际要返回到 api 的时候,可能要隐藏掉一些字段,在 Java 里面,会抽象的一个叫 DTO 的对象,它只是用来传输用的,同理,在我们 Go 里面,实际也会把这些 model 的一些结构体映射成 api 里面的结构体(基于 PB Message 生成代码后的 struct)。 Rob Pike 当时说过的一句话,a little copying is better than a little dependency,我们就遵循了这个理念。在我们这个目录结构里面,有 internal 目录,我们知道 Go 的目录只允许这个目录里面的人去 import 到它,跨目录的人实际是不能直接引用到它的。所以说,我们看到 service 有一个 model,那我的 job 代码,我做一些定时任务的代码或者是我的网关代码有可能会映射同一个 model,那是不是要把这个 model 放到上一级目录让大家共享?对于这个问题,其实我们当时内部也争论过很久。我们认为,每一个微服务应该只对自己的 model 负责,所以我们宁愿去做一小部分的代码 copy,也不会去为了几个服务之间要共享这一点点代码,去把这个 model 提到和 app 目录级别去共用,因为你一改全错,当然了,你如果是拷贝的话,就是每个地方都要去改,那我们觉得,依赖的问题可能会比拷贝代码相对来说还是要更复杂的。 这个是一个标准的 PB 文件,就是我们内部的一个 demo 的 service。最上面的 package 是 PB 的包名,demo.service.v1,这个包使用的是三段式命名,全局唯一的名称。那这个名称为什么不是用 ID?我见过有些公司对内部做的 CMDB 或者做服务树去管理企业内部微服务的时候,是用了一些名称加上 ID 来搞定唯一性,但是我们知道后面那一串 ID 数字是不容易被传播或者是不容易被记住的,这也是 DNS 出来的一个意义,所以我们用绝对唯一的一个名称来表示这个包的名字,在后面带上这一个 PB 文件的版本号 V1。 我们看第二段定义,它有个 Service Demo 代码,其实就表示了我们这个服务要启动的服务的一个名称,我们看到这个服务名称里面有很多个 RPC 的方法,表示最终这一个应用或者这个 service 要对外暴露这几个 RPC 的方法。这里面有个小细节,我们看一下 SayHello 这个方法,实际它有 option 的一个选项。通过这一个 PB 文件,你既可以描述出你要暴露的是 gRPC 协议,又暴露出 HTTP 的一个接口,这个好处是你只需要一个 PB 文件描述你暴露的所有 api。我们回想一下,我们刚刚目录里面有个 api 目录,实际这里面就是放这一个 PB 文件,描述这一个工程到底返回的接口是什么。不管是 gRPC 还是 HTTP 都是这一个文件。还有一个好处是什么?实际上我们可以在 PB 文件里面加上很多的注释。用 PB 文件的好处是你不需要额外地再去写文档,因为写文档和写服务的定义,它本质上是两个步骤,特别容易不一致,接口改了,文档不同步。我们如果基于这一个 PB 文件,它生成的 service 代码或者调用代码或者是文档都是唯一的。 依赖顺序与 api 维护 就像我刚刚讲到的,model 是一个存储层的结构体的一一映射,dao 处理一些数据读写包,比方说数据库缓存,server 的话就是启动了一些 gRPC 或者 HTTP Server,所以它整个依赖顺序如下:main 函数启动 server,server 会依赖 api 定义好的 PB 文件,定义好这些方法或者是服务名之后,实际上生成代码的时候,比方说 protocbuf 生成代码的时候,它会把抽象 interface 生成好。然后我们看一下 service,它实际上是弱依赖的 api,就是说我的 server 启动以后,要注册一个具体的业务代码的逻辑,映射方法,映射名字,实际上是弱依赖的 api 生成的 interface 的代码,你就可以很方便地启动你的 server,把你具体的 service 的业务逻辑给注入到这个 server,和方法进行一一绑定。最后,dao 和 service 实际上都会依赖这个 model。 因为我们在 PB 里面定义了一些 message,这些 message 生成的 Go 的 struct 和刚刚 model 的 struct 是两个不同的对象,所以说你要去手动 copy 它,把它最终返回。但是为了快捷,你不可能每次手动去写这些代码,因为它要做 mapping,所以我们又把 K8s 里类似 DeepCopy 的两个结构体相互拷贝的工具给抠出来了,方便我们内部 model 和 api 的 message 两个代码相互拷贝的时候,可以少写一些代码,减少一些工作量。 上面讲的就是我们关于工程的一些 layout 实践。简单回溯一下,大概分为几块,第一就是 app 是怎么组织的,app 里面有多种角色的服务是怎么组织的,第三就是一个 app 里面的目录是怎么组织的,最后我重点讲了一下 api 是怎么维护的。 Unittest 测试方法论 现在回顾一下单元测试。我们先看这张图,这张图是我从《Google 软件测试之道》这本书里面抠出来的,它想表达的意思就是最小型的测试不能给我们的最终项目的质量带来最大的信心,它比较容易带来一些优秀的代码质量,良好的异常处理等等。但是对于一个面向用户场景的服务,你只有做大型测试,比方做接口测试,在 App 上验收功能的这种测试,你应用交付的信心可能会更足。这个其实要表达的就是一个“721 原则”。我们就是 70% 写小型测试,可以理解为单元测试,因为它相对来说好写,针对方法级别。20% 是做一些中型测试,可能你要连调几个项目去完成你的 api。剩下 10% 是大型测试,因为它是最终面向用户场景的,你要去使用我们的 App,或者用一些测试 App 去测试它。这个就是测试的一些简单的方法论。 单元测试原则 我们怎么去对待 Go 里面的单元测试?在《Google 软件测试之道》这本书里面,它强调的是对于一个小型测试,一个单元测试,它要有几个特质。它不能依赖外部的一些环境,比如我们公司有测试环境,有持续集成环境,有功能测试环境,你不能依赖这些环境构建自己的单元测试,因为测试环境容易被破坏,它容易有数据的变更,数据容易不一致,你之前构建的案例重跑的话可能就会失败。 我觉得单元测试主要有四点要求。第一,快速,你不能说你跑个单元测试要几分钟。第二,要环境一致,也就是说你跑测试前和跑测试后,它的环境是一致的。第三,你写的所有单元测试的方法可以以任意顺序执行,不应该有先后的依赖,如果有依赖,也是在你测试的这个方法里面,自己去 setup 和 teardown,不应该有 Test Stub 函数存在顺序依赖。第四,基于第三点,你可以做并行的单元测试,假设我写了一百个单元测试,一个个跑肯定特别慢。 doker-compose 最近一段时间,我们演进到基于 docker-compose 实现跨平台跨语言环境的容器依赖管理方案,以解决运行 unittest 场景下的容器依赖问题。 首先,你要跑单元测试,你不应该用 VPN 连到公司的环境,好比我在星巴克点杯咖啡也可以写单元测试,也可以跑成功。基于这一点,Docker 实际上是非常好的解决方式。我们也有同学说,其他语言有一些 in-process 的 mock,是不是可以启动 MySQL 的 mock ,然后在 in-process 上跑?可以,但是有一个问题,你每一个语言都要写一个这样的 mock ,而且要写非常多种,因为我们中间件越来越多,MySQL,HBase,Kafka,什么都有,你很难覆盖所有的组件 Mock。这种 mock 或者 in-process 的实现不能完整地代表线上的情况,比方说,你可能 mock 了一个 MySQL,检测到 query 或者 insert ,没问题,但是你实际要跑一个 transaction,要验证一些功能就未必能做得非常完善了。所以基于这个原因,我们当时选择了 docker-compose,可以很好地解决这个问题。 我们对开发人员的要求就是,你本地需要装 Docker,我们开发人员大部分都是用 Mac,相对来说也比较简单,Windows 也能搞定,如果是 Linux 的话就更简单了。本地安装 Docker,本质上的理解就是无侵入式的环境初始化,因为你在容器里面,你拉起一个 MySQL,你自己来初始化数据。在这个容器被销毁以后,它的环境实际上就满足了我们刚刚提的环境一致的问题,因为它相当于被重置了,也可以很方便地快速重置环境,也可以随时随地运行,你不需要依赖任何外部服务,这个外部服务指的是像 MySQL 这种外部服务。当然,如果你的单元测试依赖另外一个 RPC 的 service 的话,PB 的定义会生成一个 interface,你可以把那个 interface 代码给 mock 掉,所以这个也是能做掉的。对于小型测试来说,你不依赖任何外部环境,你也能够快速完成。 另外,docker-compose 是声明式的 API,你可以声明你要用 MySQL,Redis,这个其实就是一个配置文件,非常简单。这个就是我们在单元测试上的一些实践。 我们现在看一下,service 目录里面多了一个 test 目录,我们会在这个里面放 docker-compose 的 YAML 文件来表示这次单元化测试需要初始化哪些资源,你要构建自己的一些测试的数据集。因为是这样的,你是写 dao 层的单元测试的话,可能就需要 database.sql 做一些数据的初始化,如果你是做 service 的单元测试的话,实际你可以把整个 dao 给 mock 掉,我觉得反而还相对简单,所以我们主要针对场景就是在 dao 里面偏持久层的,利用 docker-compose 来解决。 容器的拉起,容器的销毁,这些工作到底谁来做?是开发同学自己去拉起和销毁,还是说你能够把它做成一个 Library,让我们的同学写单元测试的时候比较方便?我倾向的是后者。所以在我们最终写单元测试的时候,你可以很方便地 setup 一个依赖文件,去 setup 你的容器的一些信息,或者把它销毁掉。所以说,你把环境准备好以后,最终可以跑测试代码也非常方便。当然我们也提供了一些命令函,就是 binary 的一些工具,它可以针对各个语言方便地拉起容器和销毁容器,然后再去执行代码,所以我们也提供了一些快捷的方式。 刚刚我也提到了,就是我们对于 service 也好,API 也好,因为依赖下层的 dao 或者依赖下层的 service,你都很方便 mock 掉,这个写单元测试相对简单,这个我不展开讲,你可以使用 GoMock 或者 GoMonkey 实现这个功能。 Toolchain 我们利用多个 docker-compose 来解决 dao 层的单元测试,那对于我刚刚提到的项目的一些规范,单元测试的一些模板,甚至是我写了一些 dao 的一些占位符,或者写了一些 service 代码的一些占位符,你有没有考虑过这种约束有没有人会去遵循?所以我这里要强调一点,工具一定要大于约束和文档,你写了约束,写了文档,那么你最终要通过工具把它落实。所以在我们内部会有一个类似 go tool 的脚手架,叫 Kratos Tool,把我们刚刚说的约定规范都通过这个工具一键初始化。 对于我们内部的工具集,我们大概会分为几块。第一块就是 API 的,就是你写一个 PB 文件,你可以基于这个 PB 文件生成 gRPC,HTTP 的框架代码,你也可以基于这个 PB 文件生成 swagger 的一些 JSON 文件或者是 Markdown 文件。当然了,我们还会生成一些 API,用于 debug 的 client 方便去调试,因为我们知道,gRPC 调试起来相对麻烦一些,你要去写代码。 还有一些工具是针对 project 的,一键生成整个应用的 layout,非常方便。我们还提了 model,就是方便 model 和 DTO,DTO 就是 API 里面定义的 message 的 struct 做 DeepCopy,这个也是一个工具。 对于 cache 的话,我们操作 memcache,操作 Redis 经常会要做什么逻辑?假如我们有一个 cache aside 场景,你读了一个 cache,cache miss 要回原 DB,你要把这个缓存回塞回去,甚至你可能这个回塞缓存想异步化,甚至是你要去读这个 DB 的时候要做归并回源(singleflight),我们把这些东西做成一些工具,让它整个回源到 DB 的逻辑更加简单,就是把这些场景描述出来,然后你通过工具可以一键生成这些代码,所以也是会比较方便。 我们再看最后一个,就是 test 的一些工具。我们会基于项目里面,比方说 dao 或者是 service 定义的 interface 去帮你写好 mock 的代码,我直接在里面填,只要填代码逻辑就行了,所以也会加速我们的生产。 上图是 Kratos 的一个 demo,基本就是支持了一些 command。这里就是一个 kratos new kratos-demo 的一个工程,-d YourPath 把它导到某一个路径去,--proto 顺便把 API 里面的 proto 代码也生成了,所以非常简单,一行就可以很快速启动一个 HTTP 或者 gRPC 服务。 我们知道,一个微服务的框架实际非常重,有很多初始化的方式等等,非常麻烦。所以说,你通过脚手架的方式就会非常方便,工具大于约定和文档这个这个理念就是这么来的。 Configuration 讲完工具以后,最后讲一下配置文件。我为什么单独提一下配置文件?实际它也是工程化的一部分。我们一个线上的业务服务包含三大块,第一,应用程序,第二,配置文件,第三,数据集。配置文件最容易导致线上出 bug,因为你改一行配置,整个行为可能跟 App 想要的行为完全不一样。而且我们的代码的开发交付需要经过哪些流程?需要 commit 代码,需要 review,需要单元测试,需要 CD,需要交付到线上,需要灰度,它的整个流程是非常长的。在一步步的环境里面,你的 bug 需要前置解决,越前置解决,成本越低。因为你的代码的开发流程是这么一个 pipeline,所以 bug 最终流到线上的概率很低,但是配置文件没有经过这么复杂的流程,可能大家发现线上有个问题,决定要改个线上配置,就去配置中心或者配置文件改,然后 push 上线,接着就问题了,这个其实很常见。 从 SRE 的角度来说,导致线上故障的主因就是来自配置变更,所以 SRE 很大的工作是控制变更管理,如果能把变更管理做好,实际上很多问题都不会出现。配置既然在整个应用里面这么重要,那在我们整个框架或者在 Go 的工程化实践里面,我们应该对配置文件做一些什么事情? 我觉得是几个。第一,我们的目标是什么?配置文件不应该太复杂,我见过很多框架,或者是业务的一些框架,它实际功能非常强大,但是它的配置文件超级多。我就发现有个习惯,只要有一个同事写错了这个配置,当我新起一个项目的时候,一定会有人把这个错误的配置拷贝到另外一个系统里面去。然后当发现这个应用出问题的时候,我们一般都会内部说一下,你看看其他同事有没有也配错的,实际这个配错概率非常高。因为你的配置选项越多,复杂性越高,它越容易出错。所以第一个要素就是说,尽量避免复杂的配置文件。配得越多,越容易出错。 第二,实际我们的配置方式也非常多,有些用 JSON,有些用 YAML,有些用 Properties,有些用 INI。那能不能收敛成通用的一种方式呢?无论它是用 Python 的脚本也好,或者是用 JSON 也好,你只要有一种唯一的约定,不需要太多样的配置方式,对我们的运维,对我们的 SRE 同时来说,他跨项目的变更成本会变低。 第三,一定要往简单化去努力。这句话其实包含了几个方面的含义。首先,我们很多配置它到底是必须的还是可选的,如果是可选,配置文件是不是就可以把它踢掉,甚至不要出现?我曾经有一次看到我们 Java 同事的配置 retry 有一个重试默认是零,内部重试是 80 次,直接把 Redis cluster 打故障了,为什么?其实这种事故很低级,所以简单化努力的另外一层含义是指,我们在框架层面,尤其是提供 SDK 或者是提供 framework 的这些同事尽量要做一些防御编程,让这种错配漏配也处于一个可控的范围,比方重试 80 次,你觉得哪个 SDK 会这么做?所以这个是我们要考虑的。但是还有一点要强调的是,我们对于业务开发的同事,我们的配置应该足够的简单,这个简单还包含,如果你的日志基本上都是写在这个目录,你就不要提供这个配置给他,反而不容易出错。但是对于我们内部的一些 infrastructure,它可能需要非常复杂的配置来优化,根据我的场景去做优化,所以它是两种场景,一种是业务场景,足够简单,一种是我要针对我的通用的 infrastructure 去做场景的优化,需要很复杂的配置,所以它是两种场景,所以我们要想清楚你的业务到底是哪一种形态。 还有一个问题就是我们配置文件一定要做好权限的变更和跟踪,因为我们知道上线出问题的时候,我们的第一想法不是查 bug,是先止损,止损先找最近有没有变更。如果发现有变更,一般是先回滚,回滚的时候,我们通常只回滚了应用程序,而忘记回滚了配置。每个公司可能内部的配置中心,或者是配置场景,或者跟我们的二进制的交付上线都不一样,那么这里的理念就是你的应用程序和配置文件一定是同一个版本,或者是某种意义上让他们产生一个版本的映射,比方说你的应用程序 1.0,你的配置文件 2.0,它们之间存在一个强绑定关系,我们在回滚的时候应该是一起回滚的。我们曾经也因为类似的一些不兼容的配置的变更,二进制程序上线,但配置文件忘记回滚,出现过事故,所以这个是要强调的。 另外,配置的变更也要经过 review,如果没问题,应该也是按照 App 发布一样,先灰度,再放量,再全量等等类似的一种方式去推,演进式的这种发布,我们也叫滚动发布,我觉得配置文件也是一样的思路。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 原文链接

有只黑白猫 2020-01-09 17:29:54 0 浏览量 回答数 0

问题

基础语言百问-Python

薯条酱 2019-12-01 20:12:27 56807 浏览量 回答数 30

回答

1.产品2.UI3.CSS4.JS5.后端(Java/php/python)6.DBA(mysql/oracle)7.运维(OP) 8.测试(QA)9.算法(分类/聚类/关系抽取/实体识别)10.搜索(Lucene/Solr/elasticSearch)11.大数据工程师(Hadoop)12.Android13.IOS14.运营 一.产品1 工作内容:了解用户需求,做竞品调研,画产品原型,写产品文档,讲解产品需求,测试产品Bug,收集用户反馈,苦练金刚罩以防止程序员拿刀砍。2 需要技能:PPT,Word, Axure,XP,MVP,行业知识,沟通。 二. UI1 工作内容:收到产品原型,给原型上色,偶尔会自作主张调整下原型的位置,出不同的风格给老板和客户选,然后听他们的意见给出一个自己极不喜欢的风格,最好给Android,IOS或者是CSS做好标注,还有的需要直接帮他们切好图,最后要练出来象素眼,看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能:PS,Illustrator,Sketch,耐性,找素材。 三. CSS1 工作内容:产品设计好原型,UI做出来了效果图,剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【PS,域名,Html,Html5,CSS,CSS3】扩展【自适应,响应式,Bootstrap,Less,Flex】 四 .JS 1 工作内容:JS工程师其实分成两类,在之前讲CSS的时候已经提到过,一个是套页面的,一个是前后端分离的。对这两个概念还是分不太清的,可以回过头去看CSS的部分。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【Http,REST,跨域,语法,组件,F12,Json,Websocket】框架【JQuery,AngularJS,Bower,RequireJS,GruntJS,ReactJS,PhoneGap】业务【金融,教育,医疗,汽车,房产等等等等各种行业】 五 .后端(Java/python/go) 1 工作内容:大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状,甚至是在某些一流的公司。很多时候都是架构师出了架构设计,更多的外包公司根本就是有DBA来做设计,然后后端程序员从JS到CSS到Java全写,完全就是一个通道,所有的复杂逻辑全部交给DB来做,这也是几年前DBA很受重视的原因。 2 需要技能:环境【IDE(Idea/Eclipse,Maven,jenkins,Nexus,Jetty,Shell,Host),源码管理(SVN/Git) ,WEB服务器(nginx,tomcat,Resin)】基础【Http,REST,跨域,语法,Websocket,数据库,计算机网络,操作系统,算法,数据结构】框架【Spring,AOP,Quartz,Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融,教育,医疗,汽车,房产等等等等各种行业】。 六 .DBA  1 工作内容:如果你做了一个DBA,基本上会遇到两种情况。一种是你的后端工程师懂架构,知道怎么合便使用DB,知道如何防止穿透DB,那么恭喜你,你只是需要当一个DB技术兜底的顾问就好,基本上没什么活可以做,做个监控,写个统计就好了。你可以花时间在MongoDB了,Hadoop了这些,随便玩玩儿。再按照我之前说的,做好数据备份。如果需求变动比较大,往往会牵涉到一些线上数据的更改,那么就在发布的时候安静的等着,等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop】工具【各种DB的版本,工具,备份,日志等】。 七. 运维  1 工作内容:运维的工作大概分成几个部分,我对于修真院学习运维的少年们都这么说,大概是:A。基础环境的搭建和常用软件的安装和配置(兼网管的还有各种程控机),常用软件指的是SVN,Git,邮箱这种,更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护,如刚刚讲到的一样,测试环境和线上环境的发布和记录,原则上,对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据,都要做好备份和回滚的手段,提前准备好各种紧急预案,服务的监制要做好。安全始终都是不怎么被重点考虑的问题,因为这个东西无底洞,你永远不知道做到什么程度算是比较安全了,所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见,大公司也是一样的。E。Hadoop相关的大数据体系架构的运维,确实有公司在用几百台机器做Hadoop,所以虽然不常见,我还是列出来吧。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop,nginx,apache,F5,lvs,vpn,iptable,svn,git,memcache,redis】工具【linux 常用工具,Mysql常用工具,Jenkins,zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容:QA需要了解需求,很多公司会要求QA写测试用例,我觉得是扯淡。完全是在浪费时间。通常开发三周,QA测试的时间只有一周到一周半。还有关于提前写测试用例的,都不靠谱。 2 需要技能:流程【Bug修复流程,版本发布流程】工具【禅道,BugZilla,Jira,Excel表格来统计Bug数,自动化测试】性格【严谨,耐心】 九. 算法工程师  1 工作内容:算法工程师的工作内容,大部分时间都是在调优。就是调各种参数和语料,寻找特征,验证结果,排除噪音。也会和Hadoop神马的打一些交道,mahout神马的,我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿,会找漂亮的小编辑去做。2 需要技能:基础【机器学习,数据挖掘】工具【Mahout,JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容: 所以搜索现在其实分成两种。一种是传统的搜索。包括:A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重,只有索引和查询。A。索引B。查询 2 需要技能:环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引,权重计算公式,去重算法,Facet搜索的原理,高亮算法,实时索引】 十一. 大数据工程师  1 工作内容:工作内容在前期会比较多一些,基础搭建还是一个挺讲究的事儿。系统搭建好之后呢,大概是两种,一种是向大数据部门提交任务,跑一圈给你。一种是持续的文本信息处理中增加新的处理模块,像我之前说的增加个分类啦,实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了,我是没有见到过的。架构稳定了之后,大数据部门的工作并不太多,常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能:环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容:Android工程师的日常就是听产品经理讲需求,跟后端定接口,听QA反馈哪款机器不兼容,闹着申请各种测试机,以及悲催的用Android做IOS的控件。 2 需要技能:环境【Android Studio,Maven,Gradle】基础【数据结构,Java,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】 十三. IOS工程师  1 工作内容:IOS工程师的工作内容真的挺简单的,听需求,定接口。做个适配,抛弃一下iphone4。还有啥。。马丹,以我为数不多的IOS知识来讲,真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊,各种渐变,各种图片滤镜处理,其他并没有什么。支付,地图,统计这些东西。 嗯。2 需要技能:环境【Xcode】基础【数据结构,Object,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】

行者武松 2019-12-02 01:21:45 0 浏览量 回答数 0

问题

Vue面试题汇总【精品问答】

问问小秘 2020-05-25 18:02:28 7911 浏览量 回答数 2

问题

何解除黑洞?怎么一直在“清洗黑洞清洗黑洞”呢?

未来精英 2019-12-01 22:03:16 22847 浏览量 回答数 14

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

回答

Re搬到阿里云半年,平均每天宕机一次,求解决 最好是能给网站一些建议,是需要提升配置,还是怎么,如果通过提升配置能解决问题,也可以。这样经常宕机谁受得了! ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 阿里云工程师的解答: 您好,经查您的主机经查会有io读写很高,和带宽跑满的现象,见截图,应该是您主机内部应用导致的,请您登陆主机内部核查一下。 感谢您的支持。 今早上9点宕机一次;这是今晚6点多刚才宕机的后台监控截图,CPU占用50%不到;磁盘读写早上9点宕机的时候比较高,晚上6点宕机的时候也不算很高;5M的带宽肯定没用满。 又宕机了,烦啊! ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 唉,早晚得重启一次。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 今天上午11点10分又宕机了,截个图,大家帮我看看。 昨天将网站首页较大的图片禁止掉,有所好转,今天上午还是宕机了。我买的是标准A型的,2核处理器、1.5G内存、5M带宽,服务器流量确实不是很大,上面两个区县级的小论坛,每天IP只有3000个。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 引用第16楼ap9211a0k于2012-12-18 10:51发表的  : 看linux中top中wa比例 如果这个比例高的花,应该是磁盘io。 可以修改网站对图片到客户端的缓存时间,以及程序对磁盘的读写,来解决 建议使用nginx代替apache,因为nginx的静态效果比apache好很多,直接命令安装就可以了。 如果你用的是windows,我上面的就当白说了,呵呵 我用的就是nginx ------------------------- ReRe搬到阿里云半年,平均每天宕机一次,求解决 引用第15楼rat_cocu于2012-12-18 10:01发表的 Re搬到阿里云半年,平均每天宕机一次,求解决 : 是不是环境设置的问题呢?希望阿里出一个比较稳定傻瓜化的环境配置系统,这样也可以大大减轻售后的压力啊! 是啊,大部分站长以前都是VPS,我虽然也在学习linux,不过一下子上手也没那么快。特别是服务器优化方面很多站长都不是很熟悉。 ------------------------- ReRe搬到阿里云半年,平均每天宕机一次,求解决 引用第14楼ouotuo于2012-12-18 09:42发表的 Re搬到阿里云半年,平均每天宕机一次,求解决 : 以前我有一台机器也卡死呢。。。后来技术人员帮我移一下机器就没事了。你叫他帮你移一下呢。 移机器麻烦吗? ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 可以ping通 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 disucz本身都是伪静态,唉,基本是一天重启两次。 ------------------------- Re搬到阿里云半年,平均每天宕机一次,求解决 我宕机的问题终于解决了。主要原因还是我两个网站的数据库大了,直接在云服务器上建数据库不知道是磁盘IO的问题还是最大连接数做了限制,导致频繁宕机。后来买了个最低端的关系型数据库RDS,问题得到解决。 另外日志文件和数据库文件太多也会导致云主机速度慢,要经常清理日志文件。 希望遇到类似情况的XD少走弯路,网站数据库大于500M的还是弄个RDS保险。

plcsq 2019-12-02 00:18:49 0 浏览量 回答数 0

问题

搞懂了这几点,你就学会了Web编程

技术小菜鸟 2019-12-01 21:20:38 2373 浏览量 回答数 1

回答

Java Java核心技术·卷 I(原书第10版)| Core Java Volume 讲的很全面,书中的代码示例都很好,很适合Java入门。 但是作者不太厚道的是把现在没人用的GUI编程放在了第一卷,基本上10~13章是可以不用读的。 Java性能权威指南|Java Performance: The Definitive Guide 市面上介绍Java的书有很多,但专注于Java性能的并不多,能游刃有余地展示Java性能优化难点的更是凤毛麟角,本书即是其中之一。 通过使用JVM和Java平台,以及Java语言和应用程序接口,本书详尽讲解了Java性能调优的相关知识,帮助读者深入理解Java平台性能的各个方面,最终使程序如虎添翼。 实战Java高并发程序设计|葛一鸣 由部分段落的行文来看,搬了官方文档。 也有一些第一人称的叙述和思考,也能看出作者也是花了一点心思的。胜在比较基础,涉及到的知识点也还很全面(讲到了流水线计算和并发模型这些边边角角的),但是由于是编著,全书整体上不够统一和深入,适合作为学习高并发的第一本工具书。 Java 8实战 对Java8的新特性讲解的十分到位,尤其是lamdba表达式和流的操作。 再者对于Java8并发处理很有独到见解。对于并行数据处理和组合式异步编程还需要更深的思考才能更加掌握。 推荐给再用java8但没有去真正了解的人看,有很多你不知道的细节、原理和类库设计者的用心良苦在里面、内容没有很难,抽出几个小时就能看完,花费的时间和收获相比,性价比很高。 Java并发编程实战 先不谈本书的内容如何,光书名就足够吸引不少目光。“并发”这个词在Java世界里往往和“高级、核心”等字眼相联系起来,就冲着这两个字,都将勾起软件工程师们埋藏在心底那种对技术的探索欲和对高级API的驾驭感。 程序员嘛,多少都有点职业病。其实Java对“并发”优化从未停止过,从5.0到7.0,几乎每个版本的新特性里,都会针对前一版本在“并发”上有所改进。这种改进包括提供更丰富的API接口、JVM底层性能优化等诸多方面。 Thinking in Java 很美味的一本书,不仅有icecreamm,sundae,sandwich,还有burrito!真是越看越饿啊~ Effective Java中文版(第3版)|Effective Java Third Edition Java 高阶书籍,小白劝退。介绍了关于Java 编程的90个经验技巧。 作者功力非常强悍,导致这本书有时知识面迁移很广。总之,非常适合有一定Java开发经验的人阅读提升。 深入理解Java虚拟机(第3版)| 周志明 浅显易懂。最重要的是开启一扇理解虚拟机的大门。 内存管理机制与Java内存模型、高效并发这三章是特别实用的。 Java虚拟机规范(Java SE 8版)|爱飞翔、周志明 整本书就觉得第二章的方法字节码执行流程,第四章的前8节和第五章能看懂一些。其他的过于细致和琐碎了。 把Java字节码讲的很清楚了,本质上Java虚拟机就是通过字节码来构建的一套体系罢了。所以字节码说的非常细致深入。 数据&大数据 数据结构与算法分析|Data Structures and Algorithm Analysis in Java 数据结构是计算机的核心,这部书以java语言为基础,详细的介绍了基本数据结构、图、以及相关的排序、最短路径、最小生成树等问题。 但是有一些高级的数据结构并没有介绍,可以通过《数据结构与算法分析——C语言描述》来增加对这方面的了解。 MySQL必知必会 《MySQL必知必会》MySQL是世界上最受欢迎的数据库管理系统之一。 书中从介绍简单的数据检索开始,逐步深入一些复杂的内容,包括联结的使用、子查询、正则表达式和基于全文本的搜索、存储过程、游标、触发器、表约束,等等。通过重点突出的章节,条理清晰、系统而扼要地讲述了读者应该掌握的知识,使他们不经意间立刻功力大增。 数据库系统概念|Datebase System Concepts(Fifth Edition) 从大学读到现在,每次拿起都有新的收获。而且这本书还是对各个数据相关领域的概览,不仅仅是数据库本身。 高性能MySQL 对于想要了解MySQL性能提升的人来说,这是一本不可多得的书。 书中没有各种提升性能的秘籍,而是深入问题的核心,详细的解释了每种提升性能的原理,从而可以使你四两拨千斤。授之于鱼不如授之于渔,这本书做到了。 高可用MySQL 很实用的书籍,只可惜公司现有的业务和数据量还没有达到需要实践书中知识的地步。 利用Python进行数据分析|唐学韬 内容还是跟不上库的发展速度,建议结合里面讲的库的文档来看。 内容安排上我觉得还不错,作者是pandas的作者,所以对pandas的讲解和设计思路都讲得很清楚。除此以外,作者也是干过金融数据分析的,所以后面专门讲了时间序列和金融数据的分析。 HBase 看完影印版第一遍,开始以为会是大量讲API,实际上除了没有将HBase源代码,该讲的都讲了,CH8,9章留到最后看的,确实有点顿悟的感觉,接下来需要系统的看一遍Client API,然后深入代码,Come ON! Programming Hive Hive工具书,Hive高级特性。 Hadoop in Practice| Alex Holmes 感觉比action那本要强 像是cookbook类型的 整个过完以后hadoop生态圈的各种都接触到了 这本书适合当参考手册用。 Hadoop技术内幕|董西成 其实国人能写这样的书,感觉还是不错的,不过感觉很多东西不太深入,感觉在深入之前,和先有整体,带着整体做深入会更好一点, jobclient,jobtracer,tasktracer之间的关系最好能系统化 Learning Spark 很不错,core的原理部分和api用途解释得很清楚,以前看文档和代码理解不了的地方豁然开朗。 不足的地方是后几章比较弱,mllib方面没有深入讲实现原理。graphx也没有涉及 ODPS权威指南 基本上还算一本不错的入门,虽然细节方面谈的不多,底层也不够深入,但毕竟是少有的ODPS书籍,且覆盖面很全,例子也还行。 数据之巅|徐子沛 从一个新的视角(数据)切入,写美国历史,统计学的发展贯穿其中,草蛇灰线,伏脉千里,读起来波澜壮阔。 消息队列&Redis RabbitMQ实战 很多年前的书了,书中的例子现在已经不适用了,推荐官方教程。 一些基础还是适用,网上也没有太多讲rab的书籍,将就看下也行,我没用过所以…. Apache Kafka源码剖析|徐郡明 虽然还没看,但知道应该不差。我是看了作者的mybatis源码分析,再来看这本的,相信作者。 作者怎么有这么多时间,把框架研究的这么透彻,佩服,佩服。 深入理解Kafka:核心设计与实践原理|朱忠华 通俗易懂,图文并茂,用了很多图和示例讲解kafka的架构,从宏观入手,再讲到细节,比较好,值得推荐。 深入理解Kafka是市面上讲解Kafka核心原理最透彻的,全书都是挑了kafka最核心的细节在讲比如分区副本选举、分区从分配、kafka数据存储结构、时间轮、我认为是目前kafka相关书籍里最好的一本。 Kafka 认真刷了 kafka internal 那章,看了个talk,算是入了个门。 系统设计真是门艺术。 RocketMQ实战与原理解析|杨开元 对RocketMQ的脉络做了一个大概的说明吧,深入细节的东西还是需要自己看代码 Redis设计与实现|黄健宏 部分内容写得比较啰嗦,当然往好了说是对新手友好,不厌其烦地分析细节,但也让整本书变厚了,个人以为精炼语言可以减少20%的内容。 对于有心一窥redis实现原理的读者来说,本书展露了足够丰富的内容和细节,却不至于让冗长的实现代码吓跑读者——伪代码的意义在此。下一步是真正读源码了。 Redis 深度历险:核心原理与应用实践|钱文品 真心不错,数据结构原理+实际应用+单线程模型+集群(sentinel, codis, redis cluster), 分布式锁等等讲的都十分透彻。 一本书的作用不就是系统性梳理,为读者打开一扇窗,读者想了解更多,可以自己通过这扇窗去Google。这本书的一个瑕疵是最后一章吧,写的仓促了。不过瑕不掩瑜。 技术综合 TCP/IP详解 卷1:协议 读专业性书籍是一件很枯燥的事,我的建议就是把它作为一本手册,先浏览一遍,遇到问题再去详细查,高效。 Netty in Action 涉及到很多专业名词新概念看英文原版顺畅得多,第十五章 Choosing the right thread model 真是写得太好了。另外结合Ron Hitchens 写的《JAVA NIO》一起看对理解JAVA NIO和Netty还是很有帮助的 ZooKeeper 值得使用zookeeper的人员阅读, 对于zookeeper的内部机制及api进行了很详细的讲解, 后半部分深入地讲解了zookeeper中ensemble互相协作的流程, 及group等高级配置, 对zookeeper的高级应用及其它类似系统的设计都很有借鉴意义. 从Paxos到Zookeeper|倪超 分布式入门鼻祖,开始部分深入阐述cap和base理论,所有的分布式框架都是围绕这个理论的做平衡和取舍,中间 zk的原理、特性、实战也讲的非常清晰,同时讲cap理论在zk中是如何体现,更加深你对cap的理解. 深入理解Nginx(第2版)|陶辉 云里雾里的快速读了一遍,主要是读不懂,读完后的感受是设计的真好。 原本是抱着了解原理进而优化性能的想法来读的,却发现书中的内容都是讲源码,作者对源码的注释超级详细,非常适合开发者,但不适合使用者,给个五星好评是因为不想因为我这种菜鸡而埋没了高质量内容。 另外别人的代码写的真好看,即便是过程式语言程序也吊打我写的面向对象语言程序。 作者是zookeeper的活跃贡献者,而且是很资深的研究员,内容比较严谨而且较好的把握住了zk的精髓。书很薄,但是没有废话,选题是经过深思熟虑的。 深入剖析Tomcat 本书深入剖析Tomcat 4和Tomcat 5中的每个组件,并揭示其内部工作原理。通过学习本书,你将可以自行开发Tomcat组件,或者扩展已有的组件。 Tomcat是目前比较流行的Web服务器之一。作为一个开源和小型的轻量级应用服务器,Tomcat 易于使用,便于部署,但Tomcat本身是一个非常复杂的系统,包含了很多功能模块。这些功能模块构成了Tomcat的核心结构。本书从最基本的HTTP请求开始,直至使用JMX技术管理Tomcat中的应用程序,逐一剖析Tomcat的基本功能模块,并配以示例代码,使读者可以逐步实现自己的Web服务器。 深入理解计算机系统 | 布莱恩特 无论是内容还是纸张印刷,都是满分。计算机学科的集大成之作。引导你如何练内功的,算是高配版本的计算机导论,目的是釜底抽薪引出来操作系统、组成原理这些专业核心的课程。帮助我们按图索骥,点亮一个一个技能树。 架构探险分布式服务框架 | 李业兵 刚看前几章的时候,心里满脑子想得都是这特么贴一整页pom文件代码上来干鸡毛,又是骗稿费的,买亏了买亏了,后来到序列化那章开始,诶?还有那么点意思啊。 到服务注册中心和服务通讯,60块钱的书钱已经赚回来了。 知识是无价的,如果能花几十块钱帮你扫了几个盲区,那就是赚了。 深入分析JavaWeb技术内幕 | 许令波 与这本书相识大概是四年前是在老家的北方图书城里,当时看到目录的感觉是真的惊艳,对当时刚入行的自己来说,这简直就是为我量身定做的扫盲科普集啊。 但是可惜的是,这本书在后来却一直没机会读上。然后经过四年的打怪升级之后,这次的阅读体验依旧很好。 其中,java编译原理、 Servlet工作原理、 Tomcat、spring和iBatis这几章的收获很大。 前端 jQuery 技术内幕| 高云 非常棒的一本书,大大降低了阅读jquery源码的难度(虽然还是非常难)。 Head First HTML与CSS(第2版) 翻了非常久的时间 断断续续 其实从头翻到尾 才发现一点都不难。 可我被自己的懒惰和畏难情绪给拖累了 简单说 我成了自己往前探索的负担。网页基础的语法基本都涵盖了 限于文本形态 知识点都没法像做题一样被反复地运用和复习到。通俗易懂 这不知算是多高的评价? 作为入门真心算不错了 如果更有耐心 在翻完 HTML 后 对 CSS 部分最好是可以迅速过一遍 找案例练习估计更好 纸上得来终觉浅 总是这样。 JavaScript高级程序设计(第3版) JavaScript最基础的书籍,要看认真,慢慢地看,累计接近1000小时吧。而且对象与继承,性能优化,HTML5 api由于没有实践或缺乏代码阅读量导致看的很糊涂,不过以后可以遇到时再翻翻,或者看更专业的书。 深入理解ES6 Zakas的又一部杰作,他的作品最优秀的地方在于只是阐述,很少评价,这在帮助我们夯实基础时十分有意义,我也喜欢这种风格。 我是中英文参照阅读的,译本后半部分有一些文字上的纰漏,但是总体来说忠实原文,水平还是相当不错,希望再版时可以修复这些文字问题。 高性能JavaScript 还是挺不错的。尤其是对初学者。总结了好多程序方面的好习惯。 不过对于老手来说,这些常识已经深入骨髓了。 深入浅出Node.js|朴灵 本书是我看到现在对Node.JS技术原理和应用实践阐述的最深入,也最全面的一本书。鉴于作者也是淘宝的一位工程师,在技术总是国外好的大环境下,没有理由不给本书五颗星。 作者秉着授人于鱼不如授人于渔的精神,细致入微的从V8虚拟机,内存管理,字符串与Buffer的应用,异步编程的思路和原理这些基础的角度来解释Node.JS是如何工作的,比起市面上众多教你如何安装node,用几个包编写一些示例来比,本书绝对让人受益匪浅。 认真看完本书,几乎可以让你从一个Node的外行进阶到专家的水平。赞! 总结 其实我觉得在我们现在这个浮躁的社会,大家闲暇时间都是刷抖音,逛淘宝,微博……他们都在一点点吞噬你的碎片时间,如果你尝试着去用碎片的时间看看书,我想时间久了你自然能体会这样的好处。 美团技术团队甚至会奖励读完一些书本的人,很多公司都有自己的小图书馆,我觉得挺好的。 文章来自:敖丙

剑曼红尘 2020-03-20 14:52:22 0 浏览量 回答数 0

问题

为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗?【Java问答学堂】46期

剑曼红尘 2020-06-29 16:39:00 6 浏览量 回答数 1

回答

回楼主北京亿网的帖子 感谢你的关注,以后有什么问题可以咨询我们北京亿网,由于给客户上了一台阿里云产品,深深体会到了客户的不容易,我们亲自沟通都不行,最后还是自己查出原因,投诉什么的是没用的,你自己生气还不如自己想办法,指不上,第三方公司一等一小天,并且真的问题他们也是处理不了,只有普通客户的问题才能解决估计,比如这次,一分钟就明白的事,万网和第三方弄四天,我们客户急了都,没办法我们通地不断检查测试,查清原因了. ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 引用楼主北京亿网于2014-12-06 08:15发表的 使用阿里云ECS无法安装SQL2005系统的问题 : 问题描述 : 在安装mssql2005时,安装CD1顺利完成,在安装CD2时无法进行,双击安装文件后自动关闭,无提示!怎么解决? 看的日志提示是: 事件 ID ( 11260 )的描述(在资源( MsiInstaller )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述;查看帮助和支持以了解详细信息。下列信息是事件的一部分: 产品: Microsoft SQL Server 安装程序支持文件(英语) -- 错误 1260。由于一个软件限制策略的阻止,Windows 无法打开此程序。要获取更多信息,请打开事件查看器或与系统管理员联系。 ....... [url=http://bbs.aliyun.com/job.php?action=topost&tid=187191&pid=tpc][/url] 服务态度还行,就是服务方式不好,回复你的售后基本可以讲不算是一名技术人员,他不这样说也没什么可说的了,不过有一点说的没错,你这边不急不投诉他真不给你重视起来呢,你说怪不怪! ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 问题已经自行查明原因,阿里提供镜象问题,暂时还无法加其他版本镜象,只能更换系统. ------------------------- 回6楼云追溯的帖子 好久没来阿里云论坛了,今天打开一看自己的贴子又跑首页了,你们就别指着给你解决什么,就一个弄清问题叫他们承认都要用我一个来月的时间,最后的结果是清楚原因,但不能给解决,只能逼着你换系统,所以别指望了,如果实在用不了,还是用我们的产品吧,还有代维服务,我们给客户代购的阿里云产品叫我们技术部操了不少心,要是我们的产品直接帮解决了,我这只能帮查出问题,叫人家解决,但后台没几个技术是专业的,全是叫第三方给查看,就算指出原因,也不会给解决,估计是反应不上去,没人重视,只要广告打的响,你们这些用不了的还不如新来的人多,不可能重视,大公司没办法! ------------------------- 回7楼ftp4oss的帖子 你的企业版2005数据库是装在阿里云2003系统上的吗,要是装2008系统上的这种另类反搭配就别在这讲了,那不如直接装SQL2008了.这个贴子的前题时指2003系统通常搭配的2005数据库无法安装的问题.原因是阿里云没有提供专业的服务器版系统静象,这种不专业的系统来当服务器系统,也只能装个人用的精简的数据库2005,企业的装不了. ------------------------- 回8楼拔刀斋的帖子 阿里云的技术支持仅限安装系统这部分,然后有什么问题安装什么他们也没个专业的技术来判断,只会告诉你支持,或是没限制,事实不是这样,因为他们提供的系统本身就有局限,等你问个半个月了也搞不了,他们换几个技术也搞不了时,会推荐你叫第三方服务,基本上所谓的第三方也没有几个专业的,提问一次两三天有个结果吧,建议没有技术力量的客户不要在折磨自己了,因为你搞什么想弄个对错都没有人帮你去判断!如果一定用阿里云可以联系我们代购,至少我们负责代维,不是他们后台不专业的技术说什么是什么,就是不给解决他也得承认我们查出的问题,到时你想退款也有依据.如果就是租了一个月也别退了,就当交学费了,直接在我们这买产品,我们可以代购阿里云,也有自己的产品,包维护,支持环境应用技术支持. ------------------------- 回9楼中国舞曲网的帖子 SQL2000这个版本有点低了,几年前我们就不装这种环境了,没有试,是不是阿里系统静象问题也不好说,如果还是那个静象那就是有问题,虽然此前有一个用户和我说同样的静象版本在另一个区购买的高配置就可以安装,这个我没亲自看,所以也不确定他说的是不是真实的,总之吧,服务器系统应用服务器版系统才是专业的,用什么标准,,精简,就是能装上以后也会有各种各样的问题,不专业的表现,配套能装上的也全是一些精简的个人研究之用的数据库版本,所以从专业角度就是系统问题,从相对论上来说,装个个人研究之用的数据库2005我也可以给客户装上,但那是精简的,你懂的! ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 好久没来了,今天来看发现自己的贴子又叫顶到首页了,看来好有后来人在受困扰,那就全回复一下吧,另外有一些看了广告就来买阿里云又不会用的,又不会装环境的亲们,来北京亿网寻求帮助吧,提供代维服务. ------------------------- 回7楼ftp4oss的帖子 你要不是提供个截图我还真以为你装了个企业版,我贴子中似乎有讲过在我们遇到这个问题后,也有万网多名技术员测试安装无法成功,并且万网委托的第三方技术公司也未能安装成功,最后认同了我们的结论,他这个静象就不能装企业版2005,用一些方法装上后在以后使用和更新时会更多的麻烦,所以放下研究真的使用这样免强装上是不行的,但你这里还截了图,还安静的讲装上了还用了一年多,,为了不叫看我贴的其他用户叫你误导,本楼主在此有必要回复一下,你讲的可能是一个事实,但你截图的这个版本并不是企业版SQl2005,从你截图显示的版本号1399来看,似乎是开发版,并不是真正的企业版,所以和我讲的阿里云目前的提供的2003系统并不能完美安装SQL2005企业版不是同一个问题.看签名你还是级别: 工具与镜像服务商 ?那就向万网要求提供下服务器版2003静象吧,这样专业一些,能适合不同版SQL2005,就不会有这么多客户的各种问题了,我没有时间在建议这些. ------------------------- 回17楼数据佰度的帖子 17楼看来是真的去安装测试了,看得出 是比较认真的一个人,你的测试是正确的,万网电话客服人员普遍技术水平是零,包括后台技术的回复也是相当不负责,这一点我早早有提出过,但建议是建议,人家还是那样,从你讲的看来他们还是在和客户不停的讲这句,系统工程纯净的,全可以装,看来这个含糊不负责的回答现在想想不是他们不清楚这样回答不负责,这样回签对销量有意义,一些客户就是因为这句回答就买了,买完装不了就郁闷去吧.另外你楼上16楼他没你认真,他装的根本也不是企业版,所以他的测试没意义,你的结论是正确的. ------------------------- 回19楼围观群众1的帖子 只为了装上通过查看系统日志提示,通过结束进程,移队插件,直接用静象文件修复安装等多种方式都能完成安装过程,但这种安装并不是真的成功,特别是配套其他软件使用时,以后在更新升级时问题多多,这些最开始我们公司全有测试过,所以最后才有以上结论,阿里云这个2003系统并不是他们讲的那样可以装企业版2005,如果他们不能提供服务器版2003系统,大家就不要在浪费时间了. ------------------------- 回26楼围观群众1的帖子 这个贴子这么久还有人围观,首先感谢大家的关注和支持! 26楼看得出也是一个热爱技术和喜欢发现问题,研究问题,解决问的人,这很好! 但关于微软的系统版本和数据库版本对应问题,官方版本的划分已经是一个答案了,如果全通用还划分版本做什么,这本不是一个值得讨论的事情,此问题其根本是源于我的客户在咨询阿里售后时得到的精典答复是:系统是纯净的,全可以装"有关这个说法建议可以直接咨询微软方面,本人不过多说明,只是对热爱技术的网友回下贴,感谢关注. 你这种测试是有主观倾向的,什么也证明不了,服务器技术管理人员哪有不打补丁的呢,如果要把补丁移除才能装那本身就是个问题,为了解决一个问题而把一年的补丁移除来说明是补丁问题这相当的不可取,很危险的维护方式.补丁也是系统的一部分,并且不出意外你这种方式 装上了,在以后打补丁还会出问题,到时你来此贴报个道吧,如果只是为了能装上,方法很多,我的贴子中也有提到,但用户他租这个是用来使用的,不是一时研究之用,所以只有根本的解决方法才是真的解决,踏实的按微软的版本对应要求配置安装才是正道,其他全是取巧,如果就是暂时解决,以后服务器也是要升级补下的,如果微软某个补丁就是适于对应版本才可以时,那时才要换成对应版本吗,更何况叫服务商增加服务器版系统对客户是好事,对服务商来说也是更专业,难道租这个不是来当服务器吗 ------------------------- 回29楼兔子王的帖子 感谢围观,你这种租台机器挂QQ用的,是不需要装数据库的,所以你放不放心都没意义,更不会懂技术间讨论的那种乐趣,如果你的水平都可以来判断专业与否了,那会上网打字全是高级技术员了,如果你的乐趣就是用言语挑事,打个嗝都要说所处地气候环境不适合你生长,很不巧我向来以言语犀利 为自我评价。要不你开个贴我可以和你一样不知天高地厚的用敲字来PK下双方的神经反应系统灵敏度。所以不要在我的贴子上面发广告,还留个QQ,还网络公司,先不说你在我贴子下留广告这是一种不尊重,其次你那所谓的解决方式不是误人子弟吗,自己坑了不要急,不能坑了客户,给别人留后患.还某人某人的,如果没有建设性的技术方案要和大这交流的就收起你的广告和管好你地张嘴. ------------------------- 回 17楼(数据佰度) 的帖子 这个人厚道,至少他清楚我发这个贴子在说什么和我的用意,这是广大用户对阿里方面要求提升服务的一种鞭策,阿里方面至少和我直接沟通的人员也很认可我讲的这一点,至少态度是友好的,并且我发这个贴子时离2003官方不在支持还有半年,有一天我们也要给客户最好的支持,这才是服务,现在我们自己都不用2003了,因为官方不支持了,这个是一个硬性依据! ------------------------- 回 29楼(兔子王) 的帖子 对,这种人你得捧,给他勇气,叫他一直傻下去,一个版本对应问题官方都有说明的事,还搞的这么复杂,没人说镜象问题,我一直在说版本,要提供服务器版本,对大众客户来说,用标准版装去装企业版数据库就会碰到这样的问题,他们不是技术人员,你叫他们每个人和你一样去这样弄几天才成就了你的自尊心是吗,你那叫解决了是吗,过了半年你现在还这样想,那你真没救了,你看你已经把这位误导了。自己偶尔的一个测试原因尚不明确就拿 出来当论据了,很不负责任做为一个技术人员! ------------------------- 北京亿网感谢大家的关注,这个贴子很久了,今天上来结下贴的,欢迎大家交流,但希望发表技术类方面的言论时不要给其他人造成误导,否则我讲话可是很直接的叫你不舒服的,为了证明我不是恶意针对某人,在这里结贴时也给感谢一下阿里方面的回复,我今天 才上来看到,这对于个别人来讲,可能看了会感觉打脸,阿里人家不需要你的跪添,所以在讨论技术问题时至少不要在我面前硬装人,看下吧,那位硬说版本没半毛钱关系的那位,顺便说句这个贴子就结了,以后大家关注北京亿网新贴子,我们已经为用户提阿里美国,香港,国内的阿里云空间产品,新加坡的也要上线了,谢谢大家来使用,联系我们吧! 下面是阿里云工程师对我们这个提问的回复,结贴了,大家以后不要在讨论了。 售后工程师 :  您好,从如下微软官方SQL Server安装说明来看,Windows Server 2003标准版确实不支持安装SQL Server 2005企业版。http://technet.microsoft.com/zh-cn/library/ms143506(v=sql.90).aspx 当前查看您已经将服务器系统更换为2008。对于该问题给您带来的不便很抱歉。感谢您的问题反馈和对阿里云的信赖。  2014-12-29 18:35:29 ------------------------- 回 42楼(bjyw用户) 的帖子 用户您好,请别激动,也不要生气了!首先要感谢你告诉我们的账号叫封停了,你不告诉我们都不知道!刚已经联系阿里解封了,那个版主我就不点名了,他自己发的帖子植入广告别人又不是看不出来,估计当这个版主就是为了自己发广告方便才申请的吧,但你自己方便也就算了,怎么还乱用权限了呢, 有点自知之明好不好,我们下边的客户草根站长多的事,全应可以来申请版主,哪轮得到你删贴和禁言的,有事你说事啊,直接封公司的账号你脑子是不是缺点什么? 还有我这个帖子早就结贴了,那个小号上来骂骂咧咧的,某版主没见你一起封啊,用我们用户的话讲你是不是瞎?还有那个小号你也不要在这骂,我也理解你一万年解决了一个问题出来显摆下的心情,这类问题在技术部天天都有的事,我们都表示没什么可说的了,我都结贴了你怎么还没脸没皮的上来发上面的话?阿里工程师都回复,我都贴 出来了,告诉大家不要在讨论了,你看你把我们用户气的!在贴下你看看吧,无知喷人不要紧,但你也看明白人家讲什么你在喷啊,我在这里给大家讨福利的事,你在那折什么台呢,我们客户举的例子你要是看不懂,我给你举个吧:话说一个通道,客户人家就要正常的直接走过去,因为一直这样走,可你一定要来个左三步,右三步,退一步,进两步,搞的和过关一样,最后也能过去,或者叫用户记得这个口决每次也可以过去,你认为这个就不需要解决了是吧?问题是客户为什么要记这些,会这些呢,人家的软件又无问题,人家客户又不想聘个技术人员,如果说一次免费两次免费我们可以帮,但经常的重装我们没事就给处理这个问题吗?为什么不能一劳永逸?明白我发贴的意思了吗?还不理解我也没办法,我承认我嘴比较黑,但对客户这块不含糊,但你看客户有骂我的吗? 下面是阿里云工程师对我们这个提问的回复,结贴了,大家以后不要在讨论了。 售后工程师 :  您好,从如下微软官方SQL Server安装说明来看,Windows Server 2003标准版确实不支持安装SQL Server 2005企业版。 http://technet.microsoft.com/zh-cn/library/ms143506(v=sql.90).aspx 当前查看您已经将服务器系统更换为2008。对于该问题给您带来的不便很抱歉。 感谢您的问题反馈和对阿里云的信赖。  2014-12-29 18:35:29 看到了吧?看清了吗?可能有人会问,你知道这个原因为什么要发求助贴呢,为什么还讨论这么久呢?能这样问的只能说你没认真看我发的相关贴子,我在最开始联系阿里方面时就告诉是这个原因,要提供一个服务器版镜象就没问题了,但阿里后台客服坚持那句话“我们的系统没有问题,可以直接装你的那个企业版2005”并且客户自己也打电话问了,也是那样回答的!所以我们只能把处理记录和进程贴出来,叫客户也看到,最后客户也完全理解我们和阿里方面了不是吗?如果说我们是为了显摆什么技术,那这类问题每天给阿里发来10个贴子, 我们还得聘一个阿里论坛编辑了,所以这个贴子完全是因为用户要看,我们才发的!如果我们经常来,也不会叫某傻X版主封号都不知道了!

北京亿网 2019-12-02 01:11:23 0 浏览量 回答数 0

问题

阿里云的远程经常断开,无法解决

boerthaaa 2019-12-01 21:59:01 10536 浏览量 回答数 4

问题

软件性能测试的本质

技术小菜鸟 2019-12-01 21:45:03 4548 浏览量 回答数 1

回答

iperf,具体要纤细直接去看文档, 简单给你列条测试:(TCP和UDP知只是两种传输数据的协议) 1)TCP测试    服务器执行:./iperf -s -i 1 -w 1M '这裏是指定windows如果是 iperf -s则windwos默认大小为8kbyte/s    客户端执行:./iperf -c host -i 1 -w 1M   其中-w表示TCP window size,host需替换成服务器地址。    2)UDP测试    服务器执行:./iperf -u -s    客户端执行:./iperf -u -c 10.255.255.251 -b 900M -i 1 -w 1M -t 60   其中-b表示使用多少带宽,1G的线路你可以使用900M进行测试。 不给分不给力 连接速度是个很怪的概念。我们通常用连接带宽和网络延迟来表达网络连接的状态。 带宽可以用一端建立FTP服务器,另一端下载来测试。网络延时可以用PING命令来测试。 希望能帮到你。 行的。 家庭或小型办公室,如果有两台或更多的计算机,很自然地希望将他们组成一个网络。为方便叙述,以下约定将其称为局域网。在家庭环境下,可用这个网络来共享资源、玩那些需要多人参与的游戏、共用一个调制解调器享用Internet连接等等。办公室中,利用这样的网络,主要解决共享外设如打印机等,此外,办公室局域网也是多人协作工作的基础设施。 别看这样小的网络工程,在过去也是需要专业人员来进行组网配置的。那时,大部分操作的都是手工的,一般的用户都不具备相应的知识和经验。正好属于"高不成低不就"的情况,自然限制了它的发展。Windows XP的出现,打破了这种局面,这依赖它内建有强大的网络支持功能和方便的向导。用户完成物理连接后,运行连接向导,可以自己探测出网络硬件、安装相应的驱动程序或协议,并指导用户,完成所有的配置步骤。 本文介绍两种在Windows XP操作系统下的组网方案,并介绍Windows XP用于局域网中的各种很有特色的功能。 一. 目标: 组成家庭局域网:对外,可以连接Internet,允许局域网内的各个计算机共享连接。对内,可以共享网络资源和设备。 二. 采用什么网络形式? 家庭网中的计算机可能有桌面机或便携机,例如掌上电脑或笔记本机等,也可能出现各种传输介质的接口,所以网络形式上,不宜都采用有线网络,无线接口是必须考虑的。但如果可以明确定位在纯粹的有线网上,也可不设无线接口。所以,这里提供两种方案: 1. 有线与无线混合。 2. 有线。 三. 网络硬件选择 网络适配器(网卡)可采用PCI、PC或PCMCIA接口的卡(后两者多用在便携式机或笔记本机上),Windows XP也支持用USB接口的网络适配器。究竟采用那种适配器,取决于接入网络中的计算机。无论那种适配器,都需要注意与现有计算机的接口以及HUB的协调一致,USB接口的适配器可能适应性更强一些,但对于较旧的计算机,又需要注意它是否支持USB接口。 网络连接线,常用的有同轴电缆和双绞线,这都是大家熟悉的东西,不多解释。究竟采用哪一种,就看你怎么想了。 四. 可采用的网络结构和介质 以太结构:这种结构在办公室或商业用户中最为流行,熟悉的人也很多,技术资料和维护人员也容易找到,所以不多赘述。 电话线连接:这种形式主要的特色是成本很低,物理连接也很简单,适用于大部分的家庭用户。 无线电波:利用电磁波信号来传输信号,可以不用任何连线来进行通讯,并可以在移动中使用。但需要在每台计算机上加装无线适配器,成本高是肯定了。在我国,无线形式用在计算机网络通讯的还较少。在美国,用于无线网络的是一个称为IEEE 802.11b的标准协议,用于计算机近距离网络通讯。在该协议支持下,可达到的网速是11 Mbps。 五. 方案之一 这是一个有线、无线混合方案,具体结构可以参看图1。这个例子中,用4台计算机组成了一个混合网络,PC1是主机,它与外部连接有3个通路: 1. 与Internet接连的调制解调器:用于整个网络的各个计算机共享上网之用。 2. 无线适配器:用于和本网络内的无线设备之间的通讯。 3. HUB:用于"带动"本网络内的下游计算机。 该方案中的PC1、PC2机,必须用Windows XP操作系统,有线部分采用的是以太网结构连接。图中的HPNA是home phoneline network adaptor的缩写,表示家庭电话线网络适配器。图中的PC3和移动计算机,并不要求非使用Windows XP操作系统不可,别的windows版本也行。移动计算机和主机之间的网络连接利用的是无线形式。 如果希望建立混合网络,这种方案已经具备典型的功能,并且不需要花费很大就可以扩充网络规模。 关于连通操作: 图1显示的结构只能表示物理连接关系,物理连接完成后,还需要进行连通操作,网络才可真正投入使用。连通操作包括局域网内部各个计算机之间的连通,和局域网与Internet之间的连通。前者连通建立的步骤如下: 1. 鼠标点击 开始,进入控制面板,点击"Network and Internet Connections网络和Internet连接",选择网络连接( Network Connections),进行下一步。 2. 选择进行"两个或多个LAN的连接" 3. 右键点击一个连接. 4. 确定完成连接任务. 局域网之内的连通操作就完成了。 再说局域网与Internet之间的连通,这种情况主要考虑速度与成本两方面的兼顾。多机上网,最省事的办法是每个机器占据一条独立的电话线,但这不是一般用户能承受起的,资源的浪费也太大。另一个办法,可以使用住宅网关,但这样成本需要增加,不是最佳途径。比较好的方法是使用一个计算机作为主机服务器。这不仅技术上可行,还有很多别的优点,如: ①:由于Windows XP有内建的防火墙,主机介于Internet和终端机之间,可以利用主机的防火墙保护局域网中的分机免受来自Internet的攻击。 ②:主机是"隐匿在" Internet和局域网之间的,充当了网关的脚色,在分机上,用户感觉好像自己是直接连在Interne上一样,察觉不到中间还有主机存在。特别是可以使局域网中的每台计算机同时上网。大大减少了设备投资。 ③:除主机必须使用Windows XP操作系统之外,局域网内的计算机可使用早期的windows版本。 ④:如果局域网中需要使用不同的媒体(例如有线和无线混合),可以利用Windows XP作为过渡的网桥。 ⑤:虽然有网络资源和设备的共享功能,但也可以限制别人对私有文件和数据的访问,特别是将文件存放在主机上的时候,更具有这种优势可用。 ⑥:利用"万能即插即用"功能,可以随时扩充局域网的规模。 六. 方案之二 下面是这种方案的结构示意图。该方案适用于小型办公室。与上一个方案比较,主要是去掉了无线部分,主机与分机之间不采用电话线连接,而是采用了电缆或双绞线连接。所有分机都通过一个HUB与主机连接到Internet上,并可以支持打印机共享。这其实就是最常见的那种局域网的结构。 该方案完成物理连接之后,还需要进行下列操作: 1. 打开网络连接文件夹或找到网络连接的图标. 2. 右键点击"connection to the Internet you want to share(共享Internet连接)"然后再右键点击"Properties(属性)" 3. 选择"Advanced(高级)"任务条。 4. 选择"Allow other networkusers to connect through this computer′s Internet connection(允许另外用户通过这个计算机连接到Internet)"检查框,并选定。 5. 点击 OK.结束操作。 启用Windows XP的防火墙,必须进行设置,不设置是不起作用的。设置过程: 1.打开网络连接文件夹或找到网络连接的图标. 2.右键点击"connection to the Internet you want to share(共享Internet连接)"然后再右键点击"Properties(属性)" 3.选择"Advanced(高级)"任务条。 4. 选择"Protect my computer and network by limitingor preventing access to this computer from the Internet(利用这个计算机限制从Internet进入的访问并保护我的计算机和网络" ,在其下面有一个Internet连接防火墙的检查框,鼠标点击选定。 5. 点击 OK.结束操作。 七. 几点说明 A.主机必须采用Windows XP操作系统,局域网内的计算机可以使用早一些的windows版本,如:windows98、windows ME、windows2000等等。 B.这里提供的是典型的情况,想扩充网络规模基本上可以照此叠加。 C.本文是依据英文测试版本进行的试验,不能保证将来的正式版本。特别是中文正式版本的性能与此完全一致。 参考资料: 创建局域网及配置管理 一.概念: (一).局域网的概念: 局域网做为网络的组成部分,发挥了不可忽视的作用。我们可以用Windows 9X把众多的计算机联系在一起,组成一个局域网,在这个局域网中,我们可以在它们之间共享程序、文档等各种资源,而不必再来回传递软盘;还可以通过网络使多台计算机共享同一硬件,如打印机、调制解调器等;同时我们也可以通过网络使用计算机发送和接收传真,方便快捷而且经济。 局域网是一个范围可大可小、简单的只有2台运行着Windows95的计算机连网(以工作组方式工作),也可以是幅员辽阔的高速ATM网和以太网混合使用、运行多种平台的大型企业。 (二).网络的类型: 1、按网络的地理位置分类 a.局域网(LAN):一般限定在较小的区域内,小于10km的范围,通常采用有线的方式连接起来 b.城域网(MAN):规模局限在一座城市的范围内,10~100km的区域。 c.广域网(WAN):网络跨越国界、洲界,甚至全球范围。 目前局域网和广域网是网络的热点。局域网是组成其他两种类型网络的基础,城域网一般都加入了广域网。广域网的典型代表是Internet网。 (二).硬件指南:网络硬件设备 组成小型局域网的主要硬件设备有网卡、集线器等网络传输介质和中继器、网桥、路由器、网关等网络互连设备。以下主要介绍网卡、集线器等网络传输介质和中继器、网桥、路由器、网关等局域网互连设备。 1.网卡 网卡(Network Interface Card,NIC)也叫网络适配器,是连接计算机与网络的硬件设备。网卡插在计算机或服务器扩展槽中,通过网络线(如双绞线、同轴电缆或光纤)与网络交换数据、共享资源。 Realtek 10/100M,这是我们实例中所使用的网卡 二.组网: 返回顶部 (一).硬件配置:服务器:普通PC机,主板:intel 815,硬盘:迈拓40G,CPU:PIII933,内存:512M ,显示器:ACER。 其他:双绞线一箱(300m),16口HUB一个,RJ45头32个,网卡:Realtek 10/100M 16块。。 由于服务器需要安装两块网卡来用SyGate维护管理,两个网卡的设置请参阅如下的动画。 三.网络维护: 返回顶部 SyGate 4.0是一种支持多用户访问因特网的软件,并且是只通过一台计算机,共享因特网帐号,达到上网的目的。使用SyGate 4.0,若干个用户能同时通过一个小型网络(包括您的笔记本电脑),迅速、快捷、经济地访问因特网。SyGate 4.0能在目前诸多流行的操作系统上运行,譬如:Windows95、Windows98、Windows NT, Windows2000等操作系统;同时,SyGate 4.0还支持多数的因特网连接方式,这包括:调制解调器(模拟线路)拨入、ISDN(综合业务数字网)、线缆调制解调器(Cable Modem)、ADSL以及DirectPC等方式。 SyGate 4.0具有以下优势: 易于安装 SyGate在数分钟之内便可以安装完成,并且通常不需要其他外加的设置。和其他代理服务器软件(proxy server)不同的是,SyGate仅安装Server便可以了。 易于使用 SyGate拥有直观的图形化界面,懂得操作Windows的人员均会操作。SyGate启动后便在后台运行,不需要人工的干预。当SyGate检测到局域网内有上网 要求时,它能自动地连接到因特网上,免去了每次需要手工拨号的烦恼。用户可以不间断地、透明地浏览因特网、收发电子邮件、聊天、使用FTP以及操作其他的小程序等等。局域网内非Windows用户,如Macintosh、Solaris和Linux,均能通过TCP/IP协议上网。 四.Windows 对等网创建与维护 返回顶部 (一).建网软件要求 在一个局域网中,Windows 95、98、NT和2000等操作系统可以并存。当然,即使你的电脑是在DOS下面跑的,也可以实现联网。由于Windows操作系统才是广泛应用的系统,本文不准备讨论DOS联网。 建网硬件要求 要组建电脑网络,无疑需要能将电脑连在一起的硬件设备。最简单的办法是,使用特制的电缆,将两台电脑的并口或者串口联接起来,通过Windows的“直接电缆连接”实现联网。这种联接电缆可以自制,也可以到电脑城购买。其缺点是,只能联接两台电脑,联网距离较短、方式古板,实际应用很不方便,通常要求将一台电脑用作服务器,另外一台用作客户端来实现联网。 但更为普遍采用的是网卡加网线的联网方式。从插槽上分,网卡有ISA和PCI两种;从速度上分,网卡又有10MB和100MB甚至传输速度更高的网卡。要求不高的话,一块PCI 10MB网卡就够用了。 五.疑难解答 返回顶部 (一).网卡安装故障检查方法 如果无法安装网卡驱动程序或安装网卡后无法登录网络,请按下述步骤检查处理: 1.选择“控制面板”/“系统”图标,打开“系统属性”窗口; 2.在“系统属性”窗口的“设备管理”标签的“按类型查看设备列表”中,双击“网络适配器”条目前的“ ”号将其展开,其下应当列出当前网卡; 3.如果“设备管理”标签中没有“网络适配器”条目或当前网卡前有一“X”号,说明系统没能识别网卡,可能产生的原因有网卡驱动程序安装不当、网卡硬件安装不当、网卡硬件故障等等; 参考 LAN(局域网)一词指位于同一区域甚至同一建筑物内的中小型计算机网络,字典上的解释是:将计算机和字处理机等电子办公设备连接在一起构成的办公室或建筑物内的网络系统。相信大多数人都在学校里、当地图书馆或朋友家里。接触过局域网。 随着宽带互联网日益流行,许多人家里都有几台计算机,家庭局域网正在形成规范。通过局域网共享宽带互联网访问可降低成本,不需要每台计算机都连接调制解调器和单独的IP地址。但如何构建一个家庭局域网共享宽带互联网访问呢? 网络带宽表示 网络带宽以兆位秒Mbps测量,通常不用兆字节秒MBps表示。一个字节有八个二进制位组成,多数人都熟悉MBps。当前局域网多为10base-T(10Mbps或1.25MBps)和100base-TX(100Mbps或12.5MBps)的以太网,使用类似标准电话线的RJ-45接口,通过网络电缆把集线器(或路由器、交换器)和计算机连接起来就构成了以太网。 网络布线 开始组建家庭局域网之前,应多少了解一些可用网络电缆的区别。这取决你家中PC机需要安排的位置,因为可能需要在墙上打眼,以穿过五类网络电缆。对家里地方不宽敞的人,这可能是令人畏缩的任务,甚至不太可能。如果你想避免穿墙打眼的麻烦,无线局域网也很方便,但应注意,无线局域网通常速度不够快,花费也高的多。另一种选择可考虑10Mbps电话线套件,利用你现成的电话线在计算机之间传送数据,可购买D-Link,Linksys,3Com和Netgear等公司的产品。不想采用无线局域网的人,可选择五类双绞线网络电缆。如果对电缆不熟悉,下面列出了电子工业协会EIA关于电缆分类的解释。根据电缆的速度和质量,可将电缆分为六类: 一、二类电缆:数据传输速度低于10Mbps(普通电话线) 三类电缆:数据传输速度达16 Mbps 四类电缆:数据传输速度达20 Mbps 五类电缆:数据传输速度达100 Mbps 五类电缆增强:数据传输速度达200 Mbps 六类电缆:数据传输速度达600 Mbps 五类电缆十分普通,连接以太网费用也较低。如果你计划穿墙打眼或使用超过50英尺五类电缆,应购买细电缆,自己动手将RJ-45插头接在电缆两端。注意,别忘了电缆穿过墙之后再接RI-45插头。 连接RJ-45插头 五类电缆连接RJ-45插头并不困难,但需要专用连接工具,可从当地五金商店买一把或从朋友处借用。操作时小心剪掉约1/4英寸电缆外塑料皮,露出电缆里面8根彩色线,注意放入RJ-45连接器里面电缆线的次序: 1、白绿 2、绿 3、白橙 4、兰 5、白兰 6、橙 7、白橙 8、棕 应仔细展开8条彩色编码线,放入RJ-45插孔中,用专用工具压紧。有条件时可用RJ-45测试器验证一下是否连接可靠,以免将来麻烦。 需要的硬件 首先确保每台计算机里都安装了网卡,100base-TX或10base-T网卡,型号、尺寸任意。注意,一般选PCI网卡,各网卡速率应一致。100base-TX网卡数据传输率较高,适合于大量数据传输,如数字电影或其它大的多媒体文件。 组建局域网需要使用集线器,交换器或内置集线器的路由器,集线器只不过用于将你所有的计算机连到局域网上。如果你只有2台计算机并且不打算增加数量,可以用一段电缆直接将2台计算机连起来,缺点是你试图共享宽带互联网访问仍然有麻烦。如果你想多台计算机访问宽带互联网,使用路由器是个好主意,可以选购Netgaer,D-Link和Linksys等著名网络公司的产品。 典型的以太网使用集线器或交换器,两种设备都有单独的连接器,用于将每台计算机连接到局域网上。集线器与交换器的主要差别在于吞吐量,集线器在所有在用的端口间分配吞吐量,因此4端口100base-TX集线器每个在用的端口只有25Mbps吞吐量。交换器更贵些,但允许每个端口全速运行。 假如你准备设置一个只有单个宽带互联网连接的局域网,应确保你的DSL或有线电缆供应商给你提供的是外置调制解调器。多数外置调制解调器通过网卡连接到你的计算机,你可把具有调制解调器的那台计算机设置为路由器,虽然这并不推荐。作为一个例子,你将电话插头接入宽带调制解调器,然后经RJ-45(双绞线)电缆连至集线器/交换器/路由器,从此,你的任一台计算机都可连接到互联网上。 设置Windows网络 确保你准备在局域网上使用的每台计算机,都有足够的五类电缆已连到了集线器或路由器。现在你可能已安装了适当的网卡以及相应的驱动程序,右击“网络邻居”,选择“属性”,可以看到当前已经安装的协议和网卡。要设置网络,应确保所用的网卡已安装了TCP/IP协议。如果你使用的微软操作系统是Windows98或更高版本,网络设置相当简单,Windows网络作为操作系统的基本选项之一应该已经安装了。如果你至少在一台计算机上使用的是Windows Me,你可运行家庭网络向导,将一步步引导你完成设置。记住,你需要使用相同的组名设置你网络中的每台计算机。在Windows95/98中,需要进入网络属性,并确保所有设置为缺省。你的互联网服务供应商ISP可能已经告诉你,如何设置TCP/IP,怎样连接到互联网。你可能是静态IP地址,或是动态IP地址,取决于你的ISP。静态IP地址设置需要的时间稍长一点,如果你想给互联网用户提供服务,如FTP,Web服务器或任何其它服务,静态IP地址是不错的。如果你分配的是IP地址,你的TCP/IP协议属性获得的应是自动选择的IP地址。要检查你的计算机是否已被集线器/路由器分配了一个IP地址,可使用Windows TP配置(进入开始 传输大点的东西,用iostat 1 查看io 来源于网络,供您参考

保持可爱mmm 2019-12-02 02:20:25 0 浏览量 回答数 0

回答

转自:阿里云官网 — 知乎 写好代码,阿里专家沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家,相信同样的方法论可以复制到大部分复杂业务场景。 一文教会你如何写复杂业务代码 了解我的人都知道,我一直在致力于应用架构和代码复杂度的治理。 这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景,如何在架构和代码层面进行应对,是一个新课题。针对该命题,我进行了比较细致的思考和研究。结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。 我相信,同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景,零售通是给线下小店供货的B2B模式,我们希望通过数字化重构传统供应链渠道,提升供应链效率,为新零售助力。阿里在中间是一个平台角色,提供的是Bsbc中的service的功能。 在商品域,运营会操作一个“上架”动作,上架之后,商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一,因此涉及很多的数据校验和关联操作。 针对上架,一个简化的业务流程如下所示: 过程分解 像这么复杂的业务,我想应该没有人会写在一个service方法中吧。一个类解决不了,那就分治吧。 说实话,能想到分而治之的工程师,已经做的不错了,至少比没有分治思维要好很多。我也见过复杂程度相当的业务,连分解都没有,就是一堆方法和类的堆砌。 不过,这里存在一个问题:即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中,类似的分解手段至少有3套以上,有自制的流程引擎,有依赖于数据库配置的流程处理: 本质上来讲,这些辅助手段做的都是一个pipeline的处理流程,没有其它。因此,我建议此处最好保持KISS(Keep It Simple and Stupid),即最好是什么工具都不要用,次之是用一个极简的Pipeline模式,最差是使用像流程引擎这样的重方法。 除非你的应用有极强的流程可视化和编排的诉求,否则我非常不推荐使用流程引擎等工具。第一,它会引入额外的复杂度,特别是那些需要持久化状态的流程引擎;第二,它会割裂代码,导致阅读代码的不顺畅。大胆断言一下,全天下估计80%对流程引擎的使用都是得不偿失的。 回到商品上架的问题,这里问题核心是工具吗?是设计模式带来的代码灵活性吗?显然不是,问题的核心应该是如何分解问题和抽象问题,知道金字塔原理的应该知道,此处,我们可以使用结构化分解将问题解构成一个有层级的金字塔结构: 按照这种分解写的代码,就像一本书,目录和内容清晰明了。以商品上架为例,程序的入口是一个上架命令(OnSaleCommand), 它由三个阶段(Phase)组成。 @Command public class OnSaleNormalItemCmdExe { @Resource private OnSaleContextInitPhase onSaleContextInitPhase; @Resource private OnSaleDataCheckPhase onSaleDataCheckPhase; @Resource private OnSaleProcessPhase onSaleProcessPhase; @Override public Response execute(OnSaleNormalItemCmd cmd) { OnSaleContext onSaleContext = init(cmd); checkData(onSaleContext); process(onSaleContext); return Response.buildSuccess(); } private OnSaleContext init(OnSaleNormalItemCmd cmd) { return onSaleContextInitPhase.init(cmd); } private void checkData(OnSaleContext onSaleContext) { onSaleDataCheckPhase.check(onSaleContext); } private void process(OnSaleContext onSaleContext) { onSaleProcessPhase.process(onSaleContext); } } 每个Phase又可以拆解成多个步骤(Step),以OnSaleProcessPhase为例,它是由一系列Step组成的: @Phase public class OnSaleProcessPhase { @Resource private PublishOfferStep publishOfferStep; @Resource private BackOfferBindStep backOfferBindStep; //省略其它step public void process(OnSaleContext onSaleContext){ SupplierItem supplierItem = onSaleContext.getSupplierItem(); // 生成OfferGroupNo generateOfferGroupNo(supplierItem); // 发布商品 publishOffer(supplierItem); // 前后端库存绑定 backoffer域 bindBackOfferStock(supplierItem); // 同步库存路由 backoffer域 syncStockRoute(supplierItem); // 设置虚拟商品拓展字段 setVirtualProductExtension(supplierItem); // 发货保障打标 offer域 markSendProtection(supplierItem); // 记录变更内容ChangeDetail recordChangeDetail(supplierItem); // 同步供货价到BackOffer syncSupplyPriceToBackOffer(supplierItem); // 如果是组合商品打标,写扩展信息 setCombineProductExtension(supplierItem); // 去售罄标 removeSellOutTag(offerId); // 发送领域事件 fireDomainEvent(supplierItem); // 关闭关联的待办事项 closeIssues(supplierItem); } } 看到了吗,这就是商品上架这个复杂业务的业务流程。需要流程引擎吗?不需要,需要设计模式支撑吗?也不需要。对于这种业务流程的表达,简单朴素的组合方法模式(Composed Method)是再合适不过的了。 因此,在做过程分解的时候,我建议工程师不要把太多精力放在工具上,放在设计模式带来的灵活性上。而是应该多花时间在对问题分析,结构化分解,最后通过合理的抽象,形成合适的阶段(Phase)和步骤(Step)上。 过程分解后的两个问题的确,使用过程分解之后的代码,已经比以前的代码更清晰、更容易维护了。不过,还有两个问题值得我们去关注一下: 1、领域知识被割裂肢解什么叫被肢解? 因为我们到目前为止做的都是过程化拆解,导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程,知识没有沉淀。相同的业务逻辑会在多个Use Case中被重复实现,导致代码重复度高,即使有复用,最多也就是抽取一个util,代码对业务语义的表达能力很弱,从而影响代码的可读性和可理解性。 2、代码的业务表达能力缺失 试想下,在过程式的代码中,所做的事情无外乎就是取数据--做计算--存数据,在这种情况下,要如何通过代码显性化的表达我们的业务呢? 说实话,很难做到,因为我们缺失了模型,以及模型之间的关系。脱离模型的业务表达,是缺少韵律和灵魂的。 举个例子,在上架过程中,有一个校验是检查库存的,其中对于组合品(CombineBackOffer)其库存的处理会和普通品不一样。原来的代码是这么写的: boolean isCombineProduct = supplierItem.getSign().isCombProductQuote(); // supplier.usc warehouse needn't check if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) { // quote warehosue check if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!"); } // inventory amount check Long sellableAmount = 0L; if (!isCombineProduct) { sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList()); } else { //组套商品 OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId()); if (backOffer != null) { sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale(); } } if (sellableAmount < 1) { throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + supplierItem.getId() + "]"); } } 然而,如果我们在系统中引入领域模型之后,其代码会简化为如下: if(backOffer.isCloudWarehouse()){ return; } if (backOffer.isNonInWarehouse()){ throw new BizException("亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!"); } if (backOffer.getStockAmount() < 1){ throw new BizException("亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]"); } 有没有发现,使用模型的表达要清晰易懂很多,而且也不需要做关于组合品的判断了,因为我们在系统中引入了更加贴近现实的对象模型(CombineBackOffer继承BackOffer),通过对象的多态可以消除我们代码中的大部分的if-else。 过程分解+对象模型 通过上面的案例,我们可以看到有过程分解要好于没有分解,过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case,如果采用过程分解+对象模型的方式,最终我们会得到一个如下的系统结构: 写复杂业务的方法论 通过上面案例的讲解,我想说,我已经交代了复杂业务代码要怎么写:即自上而下的结构化分解+自下而上的面向对象分析。 接下来,让我们把上面的案例进行进一步的提炼,形成一个可落地的方法论,从而可以泛化到更多的复杂业务场景。 上下结合 所谓上下结合,是指我们要结合自上而下的过程分解和自下而上的对象建模,螺旋式的构建我们的应用系统。这是一个动态的过程,两个步骤可以交替进行、也可以同时进行。这两个步骤是相辅相成的,上面的分析可以帮助我们更好的理清模型之间的关系,而下面的模型表达可以提升我们代码的复用度和业务语义表达能力。其过程如下图所示: 使用这种上下结合的方式,我们就有可能在面对任何复杂的业务场景,都能写出干净整洁、易维护的代码。 能力下沉 一般来说实践DDD有两个过程: 1. 套概念阶段 了解了一些DDD的概念,然后在代码中“使用”Aggregation Root,Bonded Context,Repository等等这些概念。更进一步,也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。 2. 融会贯通阶段 术语已经不再重要,理解DDD的本质是统一语言、边界划分和面向对象分析的方法。 大体上而言,我大概是在1.7的阶段,因为有一个问题一直在困扰我,就是哪些能力应该放在Domain层,是不是按照传统的做法,将所有的业务都收拢到Domain上,这样做合理吗?说实话,这个问题我一直没有想清楚。 因为在现实业务中,很多的功能都是用例特有的(Use case specific)的,如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反,这种收拢会导致Domain层的膨胀过厚,不够纯粹,反而会影响复用性和表达能力。 鉴于此,我最近的思考是我们应该采用能力下沉的策略。 所谓的能力下沉,是指我们不强求一次就能设计出Domain的能力,也不需要强制要求把所有的业务功能都放到Domain层,而是采用实用主义的态度,即只对那些需要在多个场景中需要被复用的能力进行抽象下沉,而不需要复用的,就暂时放在App层的Use Case里就好了。 注:Use Case是《架构整洁之道》里面的术语,简单理解就是响应一个Request的处理过程 通过实践,我发现这种循序渐进的能力下沉策略,应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的,而是迭代演化出来的。 下沉的过程如下图所示,假设两个use case中,我们发现uc1的step3和uc2的step1有类似的功能,我们就可以考虑让其下沉到Domain层,从而增加代码的复用性。 指导下沉有两个关键指标:代码的复用性和内聚性。 复用性是告诉我们When(什么时候该下沉了),即有重复代码的时候。 内聚性是告诉我们How(要下沉到哪里),功能有没有内聚到恰当的实体上,有没有放到合适的层次上(因为Domain层的能力也是有两个层次的,一个是Domain Service这是相对比较粗的粒度,另一个是Domain的Model这个是最细粒度的复用)。 比如,在我们的商品域,经常需要判断一个商品是不是最小单位,是不是中包商品。像这种能力就非常有必要直接挂载在Model上。 public class CSPU { private String code; private String baseCode; //省略其它属性 /** * 单品是否为最小单位。 * */ public boolean isMinimumUnit(){ return StringUtils.equals(code, baseCode); } /** * 针对中包的特殊处理 * */ public boolean isMidPackage(){ return StringUtils.equals(code, midPackageCode); } } 之前,因为老系统中没有领域模型,没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的,至少我在第一眼看到这个代码的时候,是完全不知道什么意思。 业务技术要怎么做 写到这里,我想顺便回答一下很多业务技术同学的困惑,也是我之前的困惑:即业务技术到底是在做业务,还是做技术?业务技术的技术性体现在哪里? 通过上面的案例,我们可以看到业务所面临的复杂性并不亚于底层技术,要想写好业务代码也不是一件容易的事情。 业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如,如果你需要去开发Pandora,你就要对Classloader有更加深入的了解才行。 但是,不管是业务技术还是底层技术人员,有一些思维和能力都是共通的。比如,分解问题的能力,抽象思维,结构化思维等等。 用我的话说就是:“做不好业务开发的,也做不好技术底层开发,反之亦然。业务开发一点都不简单,只是我们很多人把它做“简单”了因此,如果从变化的角度来看,业务技术的难度一点不逊色于底层技术,其面临的挑战甚至更大。 因此,我想对广大的从事业务技术开发的同学说:沉下心来,夯实自己的基础技术能力、OO能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进,写好代码。我们可以在业务技术岗做的很”技术“!。

茶什i 2020-01-10 11:53:44 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播