接口

前一段时间负责负责论坛的迁移工作，对其架构进行了简单的整理。前几天看到有人说 discuz的介绍很少，因此整理了一下，发布出来。 也是第一次发表文章，大侠们手下留情。 Discuz 整体架构如下图所示： 横向表示 同一层次中涉及的各个模块 ( 项目 ) 纵向表示 不同层次之间模块的关系，某些关系是如何在各层次中传递 ( 穿越 ) Discuz 架构上采用了比较流行的三层架构，即表现层，业务逻辑层，数据访问层来进行设计，并结合自己的情况进行了特殊处理。 表现层： 表现层即为上图中蓝色虚线表示 , 主要包括 :Web ， Services ， UI ， Control 。各项目主要功能为： UI 定义各种页面基类，提供 Ajax 访问访问接口。 Control 存放 Discuz 用到的自定义服务器端控件。 Services 提供外部访问接口。 Discuz 引入了一种模板引擎的机制，来实现表现层的多样化。 主要设计思想为：针对设计人员，提供纯静态页面，并提供了一套约定的语法和标签（ 具体位置在： templates ）。模板制作完成后，要进行模板导入，此时 discuz 会将静态模板进行解析将其转换成 aspx 页面，然后放到 aspx/1..n 下。如果你打开这下面的文件，会发现前端只是一个字符串拼接的过程。要进行的逻辑判断，都放到了后台代码中。后台代码只有一份，所有的 aspx

本次是在原有ApiTemplate项目之上，增加一个用户登录权限控制模块，用于验证ApiTemplate项目在面对一些简单问题时，如何抽象并支持未来的扩展。用户登录权限控制模块看上去很简单，但由于业余时间总是有限的。所以借助此机会实践一次用户敏捷开发。首先拆分模块，本次只实现用户登录和登出。 apitemplate项目地址： https://github.com/cqhaibin/ApiTemplate 一、总结放前面 最小化任务范围 本次任务只限定在了《用户名+密码登录》这个任务上，并且不包含数据的持久化， 这样在做的时候反复考查自己，不让自己超出范围。所以 查询用户注册信息、在线用户存储相关接口只做定义和模拟实现，不做具体的存储实现 考虑到业务逻辑是稳定的，而存储是可变的，所以数据库实体对象与业务实体对象分离 给任务一个期限 像本次就只列出了任务的期限，而没有列出每个子阶段的期限，如：一个需求必须要经过需求分析、模块设计、代码实现等阶段。这些子阶段也需要给出具体的期限。 从外向里逐层推进 定义UI/服务层接口 因为UI接口有多种提供方式（如：rest api, rpc等），所以基本以服务层接口为标准，UI接口层只是做了一次简单转换和调用。其中UI/服务层接口输入/输出参数的Moddel也随之定义（两层共享Model） 实现服务层接口 此步实现服务层接口

WeDemo App交互时序说明文档 WeDemo客户端接入指南 WeDemo生成密钥与自签名证书指南 WeDemo后台（PHP）接入指南 来源： oschina 链接： https://my.oschina.net/u/2400070/blog/3195428

待做的： 学习框架：nameko、double、spring cloud、书 微服务的定义： 一些协同工作的小而自治的服务 微服务的核心思想： 1.自治： 1）每个微服务（APP）可以独立部署到PAAS（platform as a service）上 2）作为服务方，需要避免方暴露过多给消费而产生耦合，从而降低服务的自治性。要封装好，服务方内部实现修改，不该影响到消费方。 2.细粒度： 1）解耦：避免系统臃肿、难以维护 2）内聚性：相同的东西放在一起 3.隔离性： 1）各服务直接均通过网络调用进行通信（而不是代码调用），避免了紧耦合 2）各服务之间通过API调用，API解耦性必须要好，以保证技术的选择不被限制 3）一个黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？（独立部署） 微服务的优点： 1.细粒度-》扩展性好-》可以快速响应变化、快速交付-》可以尝试更多的新技术 2.增加了团队的自治力 3.技术异构性。可以根据不同的业务场景，选择不同的技术，来构架服务。比如某个APP对性能有特别高的要求。或者某些APP对底层数据库有特别的要求（图数据库、文档数据库、关系型数据库）。这点需要APP足够小，可以快速重写，从而降低风险。还有就是框架要支持多语言开发业务模块。 4.弹性（稳定性、可用性）：第11章，详解 5.扩展：可以很容易把独立的服务，分割出去独立部署

interface是一种特殊的class，但接口的组成比类简单，主要由 抽象方法 （abstract可以省略，但没有方法体）和 全局常量 （public static final)组成。 接口是纯抽象类 所有的成员函数都是抽象函数； 所有的成员变量都是 public static final ; 接口是为了方便类的调用 一个类如果要去 实现 某个接口，要加 implements 接口名 一个类去继承一个接口，必须覆写它的所有方法。 抽象类可以实现接口，但是接口不能继承抽象类。 一个子类可以继承多个接口（这一点秒杀抽象类，一个抽象类只能被一个子类所继承，单继承局限）： 　　interface A { public static final String MSG = "hello"; public abstract void print(); //接口的方法一定为抽象函数，但abstract可以省略。 } interface B { public abstract void fun(); //abstract可以省略。 } class X implements A,B { public void print() { System.out.println("Hi"); } public void fun () { System.out.println(MSG); } public

第二节，接口的类型 第二节.接口的类型 1）根据协议区分： http/tcp等 目前大部分产品做的接口测试涵盖涉及的主要为http协议，相对于tcp来说，http比较容易实现；使用tcp协议产品，大部分就涉及到了通讯长链接的问题。 2）根据返回类型区分： 有规则的json返回 无规则的html页面返回 有规则与无规则的区别在于接口验证的时候，校验的便捷性和明确性 根据以上两种分类，根据实际案例观察下~ 案例一.根据协议的不同 1）http协议如下图 2）socket协议如下图 这以上两种协议的主要区别，对于测试来说：一个属于短连接，一个属于长连接。 案例二.返回类型的不同 1）按规则返回的json或者其他： 2）按规则不明的返回：前后端未很好的分离网站 以上两则的区别在于，返回值的验证判断，第一个比较明显容易，第二个返回整个页面html，比对验证的时候，采取模糊匹配关键字进行 来源： https://www.cnblogs.com/VVsky/p/11193034.html

前言： 示例是很有用的，这里列举的是非常简单的小java项目。应用了spring mvc，学习本项目可以了解前怎么调用的后端？后端怎么提供的接口？怎么增加的依赖等。 本教程是在一个maven web项目基础上做的，教程如下： https://blog.csdn.net/czc9309/article/details/80304074 创建环境 idea+maven 虽然是idea开发的，eclipse也可以应用下面的代码！ spring MVC是个Controller层的框架，前端调用后端服务器的接口处理器。 springMVC在后端服务器提供接口，前端就访问这些接口。 pom.xml添加spring MVC依赖 这里只增加了springMVC的依赖。 <!-- Spring dependencies --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.1.5.RELEASE</version> </dependency> 配置web.xml 增加 spring MVC 配置，众所周知spring MVC是以servlet为基础，这里配置了 DispatcherServlet 及配置文件

go docker kubernetes 软件生产线的问题、持续集成，持续发布，以及DevOps中的技术必须通过PaaS 分布式服务化的问题。 分布式服务化的服务高可用、服务编排，服务调度、服务发现、服务路由、以及分布式服务化的支撑技术完全PaaS的菜 paas platform-as-a-Service 平台即服务 2019-04-08 整理后的服务，发现了一个极其优美的图形化结构，各个节点的边界清晰，职责分明；节点间的链路畅通，协议规整。这时我们知道我们终于走在了正确的道路上。 服务一定是围绕业务的 服务的交互是标准的 保证单一业务服务高效聚合 降低服务间的相互调用 协议标准、框架标准、 接口标准 : 接口分两种：业务内部接口，业务服务接口。无论哪种接口同样遵循标准化原则 认证鉴权协议 加密解密协议 内部接口交互协议 外围接口服务协议 各个协议各司其职，用来支撑服务通信的标准化 真正的restful： 请求参数涵盖默认语义，包括：Get（获取信息），Post（创建），Put（全量修改），Patch（部分修改），Delete（删除） https://www.infoq.cn/article/D-cBEauI4oTVqwUsx5Fk https://www.infoq.cn/article/Zo-0vtAzNStPZBFVEP4g 2019-04-04 yum install

架构设计流程 在「 如何建立架构师的立体化思维？ 」这篇文章中， 老兵哥 跟大家一起聊到架构设计涉及业务、技术、系统和时间等几个维度，也知道从技术维度可以将应用分成七层，那具体怎么做呢？今天我们继续来聊聊分层架构的设计流程，以及接口设计方法等内容。通常，我们可以将分层架构的设计流程分解为下列 4 个步骤： 第一步，结合现实情况，将系统划分成多个层次。 第二步，确定层与层之间的关系，梳理出层与层之间的交互接口。 第三步，将功能相近的接口划归到一个模块，确保模块高内聚，对外低耦合。 第四步，在此基础上进一步明晰接口的参数列表。 仅仅四个步骤就完成了架构设计吗？这会不会太简单空洞了呢？各位看官，不要着急，请听蔡老师慢慢道来，每个步骤都有极具可操作性的方法及工具。 图 5 架构设计流程 层次的切分方法 面对一个庞然大物，你该如何下手呢？不用担心，这已经给你准备了庖丁解牛的方法，轻轻松松把一个复杂的大系统变得可以掌控了。 第一刀： 按照这套方法论来进行架构设计，最理想的情况是将 X 轴切分成七层。而第一刀应该先切在业务和领域之间，即通过 API 把两边解耦。交互和业务跟用户关联度高，经常随需求变化而改动，而领域和资源相对比较稳定。 第二刀： 考虑到要完成某些业务功能，系统可能需要调用外部系统协同完成，为了保证领域层相对稳定，我们需要隔离外部系统或数据持久层变化带来的影响

什么是接口？ 接口是包含一组虚方法的抽象类型，其中每一种方法都有其名称、参数和返回值。接口方法不能包含任何实现，CLR允许接口可以包含事件、属性、索引器、静态方法、静态字段、静态构造函数以及常数。但是注意：C#中不能包含任何静态成员。一个类可以实现多个接口，当一个类继承某个接口时，它不仅要实现该接口定义的所有方法，还要实现该接口从其他接口中继承的所有方法。 什么是抽象类？ 抽象类提供多个派生类共享基类的公共定义，它既可以提供抽象方法，也可以提供非抽象方法。抽象类不能实例化，必须通过继承由派生类实现其抽象方法，因此对抽象类不能使用new关键字，也不能被密封。如果派生类没有实现所有的抽象方法，则该派生类也必须声明为抽象类。另外，实现抽象方法由overriding方法来实现。 相同点 都不能被直接实例化，都可以通过继承实现其抽象方法。 都是面向抽象编程的技术基础，实现了诸多的设计模式。 不同点 接口支持多继承；抽象类不能实现多继承。 接口只能定义抽象规则；抽象类既可以定义规则，还可能提供已实现的成员。 接口是一组行为规范；抽象类是一个不完全的类，着重族的概念。 接口可以用于支持回调；抽象类不能实现回调，因为继承不支持。 接口只包含方法、属性、索引器、事件的签名，但不能定义字段和包含实现的方法；抽象类可以定义字段、属性、包含有实现的方法。 接口可以作用于值类型和引用类型