微服务

微服务架构是由Martin Fowler在他这篇 microservices 博客中提出来的，与之对立的是monolithic架构。 monolithic架构概念 vs. 微服务架构概念 monolithic架构指的是应用被以单一单元构建。比如一个小型订餐网站包含菜品展示、下订单、在线支付等业务功能模块，该网站的后端系统应用实现了所有这些业务功能。 而微服务架构则是由一组微服务组成的架构模式。每个微服务都是一个可独立部署的完整系统。一组微服务组成微服务层（注意这里的服务层不同于monolithic架构中的服务层，那个是单系统中的功能模块分层）。微服务层上面一般是应用层，应用层通过组合使用微服务层的各个微服务而向外提供接口（比如HTTP API接口）。各个微服务可以通过RPC接口供应用层调用，比如利用Thrift、Avro。 微服务拆分方法 微服务架构中的微服务一般按照业务功能来拆分，将关联性较强的业务拆成一个微服务，比如上面订餐网站可以拆分成用户服务、订单服务、菜品服务、支付服务等。具体来说一般根据业务实体名词如订单、用户或者业务动作如登录、下载等来拆分。 数据集成 vs. 服务集成 数据集成是一种比较传统的系统集成方式，其中心是数据。比如交易系统会操作订单表和用户表，比如生成订单。而短信通知系统也会访问订单表和用户表，根据订单的状态来发出不同的短信通知给用户

微服务架构要求： 根据业务模块划分服务种类 每个服务可独立部署且互相隔离 通过轻量级API调用服务 服务需保证良好的高可用 微服务技术选型： 使用 Spring Boot 开发服务 使用 Node.js 作为服务网关反向代理调用服务 使用 Zookeeper 注册发现服务 使用 Docker 封装/部署/隔离服务 使用 Jenkins 构建发布服务 Spring Boot Spring4.0推荐使用Java代码和注解方式作为配置（去xml）， Spring Boot 遵循相关理念且采用4.0相关特性和技术，集成了主流组件，可创建一个内嵌Servlet容器的jar独立运行，且提供生产级特性（服务治理）。 Node.js Node.js 是基于ChromeV8引擎的Javascript 运行环境 ，它使用“ 事件驱动 ”且“ 异步非I/O ”的模型使其轻量且高效，Node.js的包管理器NPM是全球最大的开源库生态系统。 Node.js 是运行环境，而非Javascript类库和框架， NPM 与Java的Maven异曲同工，事件驱动把事件加入队列中轮训。Node.js采用 单线程模型 ，适用于 I/O密集型应用 （高并发网站）。 Node.js内置HTTP服务器（模块），性能和稳定性与Nginx不分伯仲。且模块体系强大，比如Web框架 Express ，Web Socket服务

自从微服务概念以来，众多的软件架构在践行着这一优秀的设计理念。各自的系统在这一指导思想下收获了优雅的可维护性，但一方面也给接口调用提出了新的要求。比如众多的API调用急需一个统一的入口来支持客户端的调用。在这种情况下API GATEWAY诞生，我们将接入、路由、限流等功能统一由网关负责，各自的服务提供方专注于业务逻辑的实现，从而给客户端调用提供了一个稳健的服务调用环境。之后，我们在网关大调用量的情况下，还要保证网关的可降级、可限流、可隔离等等一系列容错能力。 一、网关 这里说的网关是指API网关，直面意思是将所有API调用统一接入到API网关层，有网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。 1.1、单体应用 单体应用.png 业务简单，团队组织很小的时候，我们常常把功能都集中于一个应用中，统一部署，统一测试，玩的不易乐乎。但随着业务迅速发展，组织成员日益增多。我们再将所有的功能集中到一个TOMCAT中去，每当更新一个功能模块的时候，势必要更新所有的程序。搞不好，还要牵一发动全身。实在难以维护。 1.2、微服务 系统微服务化.png 单体应用满足不了我们逐渐增长的扩展需求之后，微服务就出现了

本人不才，分享一下系统架构方面的知识，个人经历：单体应用架构--->分布式架构--->微服务架构 基本概念 单体应用架构: 只有一个项目，且所有功能部署在一起 分布式架构: 一个应用拆分成不同的业务，部署在不同的服务器上；分散服务器压力； 微服务架构: 分布式架构的延伸，进一步解耦复杂业务，多个微服务可以进行组合，组合后可以构成一个相对复杂的业务系统，以满足业务需求；目的是分散业务能力； 核心要素 《大型网站技术架构》中提到5大要素 性能 可用性 伸缩性 扩展性 安全性 详情可参考《大型网站技术架构》这本书以及这篇文章 http://www.cnblogs.com/me115/p/3662421.html 理解误区 架构师就是吹牛？ “架构实际上解决的是人的问题，而概念是人认识这个世界的基础”-----引自资深架构师王概凯《架构漫谈》架构师是一个很宽泛的说法，目的是为了解决实际问题与业务瓶颈； 分布式与集群？ 一个是工作方式，一个是物理形态，分布式是指将不同的业务分布在不同的地方；而集群指的是将几台服务器集中在一起，实现同一业务；分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的； 个人小结 入行近两年，业务越写越顺，坑越踩越多，最近开接触架构相关知识，参加过几次线下活动； 职业升级路线：初级工程师--->中级工程师--->高级工程师--->资深专家--->架构师

自去年以来，微服务受到了前所未有的关注，众多的互联网巨头开始实施微服务架构并取得了不错的反响，话不多说，今天我们就为大家盘点一下谷歌、亚马逊等十大科技公司的微服务实践案例。 1. 谷歌 拥有多元化微服务的大规模生态系统运行情况如何呢？ eBay和Google采用了数百到数千个单独的服务来协同工作； 现在的大规模系统都是以图的形式，而不是层次式或多个连接的形式来构成服务； 服务之间相互依赖； 只有旧的大规模系统采用高度集成的方式进行组织…… 关注好雨微信服务号，回复“谷歌”，获取下载地址 2. 亚马逊 Amazon DevOps部门业务开发经理Munns列举了微服务4条使用限制： 1）单一目的 2）仅通过API进行连接 3）通过HTTPS协议进行连接 4）微服务之间大体以黑盒的方式展现…… 关注好雨微信服务号，回复“亚马逊”，获取下载地址 3. Twitter 目前能够以规模化方式运行微服务，从而解决实际问题的企业数量仍然相当有限。Twitter就是其中的典型代表，尽管其也经历过公共服务中断，但Twitter中包含上百种服务、数以万计的节点以及每项服务中的数百万RPS，是世界上规模最大的微服务应用之一…… 关注好雨微信服务号，回复“Twitter”，获取下载地址 4. SoundCloud 很多的技术文章着重介绍的都是项目后总结出的最佳实践，SoundCloud从另外的角度

安装Jhipster 安装方法 我们提供了3种Jhipster的工作方式: 本地安装,这是一个经典的方式使用Jhipster.所有都安装在你本机,可能设置起来比较复杂,但确实大多数人通常选择的方式.如有疑问,选择这个安装. 一个基于Vagrant的" 开发工具箱 ",在一个基于Ubuntu的虚拟机上集成并配置好了开发所需的所有工具(STS,Yeoman,NODE,NPM,Genterator,JAVA8,Atom,MySQL). 一个" Docker "容器版,一个安装JHipster的轻量级虚拟化的容器. 本地安装 (推荐给一般用户OSX 类Linux) 安装JAVA8 Oracle官网 . (选择) 安装一个Java构建工具. 无论你选择使用 Maven 或者 Gradle , 一般情况下你不需要安装任何东西, 因为 JHipster将会自动为你安装 Maven Wrapper 或者 Gradle Wrapper . 如果你不想使用这些wrappers,去 Maven website 或者 Gradle website 官网下载自己的安装包. 安装 git-scm.com . 如果你刚接触Git,我们建议你使用 SourceTree . 安装 the Node.js website (推荐Long Time Support版本).这也会安装NPM,NODE的包管理工具

一、前言 这篇文章本来是继续分享 IdentityServer4 的相关文章，由于之前有博友问我关于 微服务 相关的问题，我就先跳过 IdentityServer4 的分享，进行 微服务 相关的技术学习和分享。 微服务 在我的分享目录里面是放到四月份开始系列文章分享的，这里就先穿越下，提前安排 微服务 应用的开篇文章 电商系统升级之微服务架构的应用 。 本博客以及公众号 坚持以架构的思维来分享技术，不仅仅是单纯的分享怎么使用的Demo 。 二、场景 先来回顾下我上篇文章 Asp.Net Core 中IdentityServer4 授权中心之应用实战 中，电商架构由 单体式架构 拆分升级到 多网关架构 升级之前 升级之后: 然而升级之后问题又来了，由于之前增加了代理商业务并且把 授权中心 和 支付网关 单独拆出来了，这使得公司的业务订单量翻了几十倍，这个时候整个电商系统达到了瓶颈，如果再不找解决方案系统又得宕机了。 2.1 问题及解决方案 经过技术的调研及问题分析，导致这个瓶颈的问题主要有以下几个原因，只需要把下面问题解决就可以得到很大的性能提升 每天的订单量暴增，导致订单数据太大，然而整个电商系统数据存储在一个数据库中，并且是 单表 、 单数据库 （未进行读写分离），以致于订单数据持续暴增。 相关业务需要依赖订单查询，订单数据查询慢以至于拖垮数据库 整个电商系统连接数达到瓶颈

近期将总结围绕工作中微服务架构的搭建经验，编写spring cloud的应用实战，深入浅出的讲解微服务架构该如何落地。敬请期待~ 来源： oschina 链接： https://my.oschina.net/u/780061/blog/787814

微服务 现在已经很流行了，如果想让微服务架构开发变得友好，而且可以让开发者管理起来轻松一些，跟踪误差更容易，那么只要遵循本文中讲述的5个最佳实践就可以了。 1.用户代理 在请求头里面命名有意义的名字是非常重要的,如果出现了类似于系统运行缓慢,内存访问量骤增,甚至出现飙升的情况,那么从该微服务发起的请求头中，开发人员就可以很容易定位问题。在服务请求头的User-Agent属性提供逻辑名称/{service id }，这就是一个最佳实践。例：User-Agent：EmployeeSearchService 2.API版本控制 在基于REST的架构中，微服务之间是通过API互相访问对方资源。在微服务里面，API就充当着接口的角色。在编写API时，头脑一定得清晰，确保这样API不会经常变更，这件事非常重要，因为其它的微服务会调用改API,所以API方法签名只要发生调整，代码也就需要跟着进行调整。但是改变是不可避免的,因为我们不知道未来会发生什么，这真的是很讽刺的一件事,所以今天的商业策略可能在几天以后就要被淘汰掉,因此API也就必须进行修改。 作为一名架构师,面临的最大挑战就是如何应对这些变化。答案就是版本维护。对于那些重大的变化,你可以在更新API版本的同时，给消费者发起通知,告知它已经有了新版本,这样他们就可以在既定期限内迁移到新版本。在这个时间内,作为API提供者,就必须维护两个版本

## 给应用程序添加安全机制 使用Spring Security和单页应用,就像Jhipster生成的代码,你需要Ajax的登录/退出/错误页面.为了更好的使用,我们已经为这些页面配置好了Spring Security,并且已经为你生成好了所有的Javascript和HTML代码. 默认情况下, JHipster 内置了4中不同的用户: "system",只主要为审计日志 "anonymousUser", 匿名用户 "user", 拥有 "ROLE_USER" 权限的普通用户. 密码为 "user" "admin", 拥有 "ROLE_USER" 和 "ROLE_ADMIN" 权限的管理员. 默认密码为 "admin" 处于安全因素,你应该修改这些密码 HTTP Session 认证 这是一个典型的Spring Security认证机制,我们在此基础上做了显著的改善,使用HTTP Session,是一个有状态的机制,如果你计划扩展你的程序,你需要一个粘滞回话的负载均衡器,以便每个用户都在同一个服务器. 改进了 remember-me 机制 我们改进了Spring Security的 remember-me 机制,以便每个用户只有一个独立的Token,它储存在你的数据库 (关系型或非关系型数据库,这取决于你生成项目时候的选择),我们同样也储存了很多信息变准实现