`
文章列表
AngularJS能够通过XMLHttpRequest(XHR)和JSONP请求与各种后端交流,拥有通用的$http服务以进行XHR和JSONP调用,以及专门面向Restful后端接口的$resource服务   在本章中,将研究与后端通信的API与技术,特别是一下内容: 使用$http服务进行基本的XHR调用,已经进行相应的测试 利用$q服务提供的promise API进行有效的异步请求 使用$resource工厂轻松与RESTful后端进行沟通 根据后端需求构建自定义的与$resource类似的API $http API快速导览   - - GET $h ...
1.Accept属于请求头, Content-Type属于实体头。         Http报头分为通用报头,请求报头,响应报头和实体报头。         请求方的http报头结构:通用报头|请求报头|实体报头         响应方的http报头结构:通用报头|响应报头|实体报头   2.Accept代表发送端(客户端)希望接受的数据类型。         比如:Accept:text/xml;         代表客户端希望接受的数据类型是xml类型         Content-Type代表发送端(客户端|服务器)发送的实体数据的数据类型。         比如:Content ...
上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”。 我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整 ...
软件安全本身就是个很复杂的问题,由于微服务系统中的每个服务都要处理安全问题,所以在微服务场景下会更复杂。David Borsos在最近的伦敦微服务大会上作了相关内容的演讲,并评估了四种面向微服务系统的身份验证方案。 ...
微服务架构的设计模式   前不久,Java Code Geeks发表了一篇文章,分析单体应用与微服务的优缺点。近日,该网站又发表了一篇文章,提供了六种微服务架构的设计模式。   聚合器微服务设计模式   这是一种最常用也最简单的设计模式,如下图所示:     聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面,将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务,对检索到的数据增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则。另外,每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务,那么它也有自己的缓存和数据库。聚合器可以沿 ...
微服务(micro services)这个概念不是新概念,很多公司已经在实践了,例如亚马逊、Google、FaceBook,Alibaba。微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务,每个服务都可以很容易得局部改良。 Micro这个词意味着每个服务都应该足够小,但是,这里的小不能用代码量来比较,而应该是从业务逻辑上比较——符合SRP原则的才叫微服务。   暂且不讨论大小问题,读者朋友你首先要考虑的是如何解决目前技术团队遇到的开发问题、部署问题。正是在解决这些问题的过程中,才渐渐总 ...
这是用微服务开发应用系列博客的第七篇也是最后一篇。第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点;接续文章讨论了微服务架构不同方面:使用API网关,进程间通信,服务发现,事件驱动数据管理以及部署微服务。本篇,我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略。   希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构。也许微服务架构比较适合你的应用。也许你正在开发一个大型、复杂单体式应用,日常开发和部署经验非常缓慢和痛苦,而微服务看起来是远方一个极乐世界。幸运的是,有可以参考的脱离苦海的策略,本篇文章中,我将描述如何逐步将单体式应用迁移到微服务架构 ...
【编者的话】这篇博客是用微服务建应用的第六篇,第一篇介绍了微服务架构模板,并且讨论了使用微服务的优缺点。随后的文章讨论了微服务不同方面:使用API网关,进程间通讯,服务发现和事件驱动数据管理。这篇文章,我 ...
【编者的话】本文是使用微服务创建应用系列的第五篇文章。第一篇文章介绍了微服务架构模式,并且讨论了使用微服务的优缺点;第二和第三篇描述了微服务架构模块间通讯的不同方面;第四篇研究了服务发现中的问题。本篇中,我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。   1.1 微服务和分布式数据管理问题   单体式应用一般都会有一个关系型数据库,由此带来的好处是应用可以使用 ACID transactions,可以带来一些重要的操作特性: 原子性 – 任何改变都是原子性的 一致性 – 数据库状态一直是一致性的 隔离性 – 即使交易并发执行,看起来也是串行的 Durable ...
这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中,我们将会探讨服务发现相关问题。   为什么要使用服务发现?   设想一下,我们正在写代码使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口)。传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的。例如,代码可以从一个经常变更的配置文件中读取网络位置。   而对于一个现代的,基于云微服务的应用来说,这却是一个很麻烦的问题。其架构如图所示: ...

REST和认证

我们在设计REST(Representational State Transfer)风格的Web service API,有一个问题经常要考虑,就是如何设计用户认证的体系(Authentication).   比较传统的做法是首先有一个登陆的API,然后服务器返回一个session ID,后续的操作客户端都必须带上这个session ID,但是这样的,服务就变成了有状态了,不符合REST风格的原则。另外,由于负载均衡的存在,必须有公共存储来保存用户的Session,这也增加了系统的复杂度。   所以比较好的做法是每次都传递认证信息,这样系统就是无状态的,当然由于每次都需要认证,必然降低 ...
【编者的话】这是采用微服务架构创建自己应用系列第三篇文章。第一篇介绍了微服务架构模式,和单体式模式进行了比较,并且讨论了使用微服务架构的优缺点。第二篇描述了采用微服务架构应用客户端之间如何采用API Gateway方式进行通信。在这篇文章中,我们将讨论系统服务之间如何通信。   简介   在单体式应用中,各个模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是一个基于微服务的分布式应用是运行在多台机器上的。一般来说,每个服务实例都是一个进程。因此,如下图所示,服务之间的交互必须通过进程间通信(IPC)来实现。       后面我们将会详细介绍IPC技术,现在我们先 ...
【编者的话】本系列的第一篇介绍了微服务架构模式。它讨论了采用微服务的优点和缺点,除了一些复杂的微服务,这种模式还是复杂应用的理想选择。   当你决定将应用作为一组微服务时,需要决定应用客户端如何与微服务交互。在单体式程序中,通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中,每一个微服务暴露一组细粒度的服务提供点。在本篇文章中,我们来看它如何影响客户端到服务端通信,同时提出一种API Gateway的方法。   介绍   假定你正在为在线购物应用开发一个原生手机客户端。你需要实现一个产品最终页来展示商品信息。   例如,下面的图展示了你在亚马逊Android客户端上滑 ...
【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战。正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足。   这 ...
spring 顶级项目: Spring IO platform:用于系统部署,是可集成的,构建现代化应用的版本平台,具体来说当你使用maven dependency引入spring jar包时它就在工作了。 Spring Boot:旨在简化创建产品级的 Spring 应用和服务,简化了配置文件, ...
Global site tag (gtag.js) - Google Analytics