应用架构

SpringCloud微服务应用入门 微服务架构概述 单体应用架构的不足 认识微服务架构 微服务架构的主要构成 搭建SpringCloud微服务应用 开发eureka服务器（即服务发现组件） 开发服务组件 开发zuul（网关组件） 案例源码地址 微服务架构概述 单体应用架构的不足 所谓单体应用是指一个归档文件（如war文件）包含所有功能的应用，是一种应用广泛的传统项目架构，这种架构具有结构简单，部署方便的优点，当项目的规模不是很大，使用范围和并发量也都不是太大时，生产运转是比较平稳和正常的。但是，近些年随着移动互联应用的发展，项目呈现出应用场景丰富‘，规模、使用范围和并发量较大，单体应用架构的不足之处也越来越明显，主要有以下几方面： 复杂度高、维护困难、不易扩展、部署风险大； 项目采用的技术体系早已确定，新技术难以引入； 可靠性不高，任何一个问题都可能导致整个应用崩溃； 对高并发缺乏良好的支持。 认识微服务架构 为了解决单体应用架构的不足和问题，人们提出了微服务架构，这种微服务架构的基本思想是将一个大的应用系拆分成许多足够简单的小规模应用，每一个小应用就是一个微服务，每个微服务都独立开发和部署，与其它微服务没有直接关系，甚至每一个微服务使用的技术可以是不相同的。 微服务架构一般具有易于开发维护和部署、技术使用不受限制、可伸缩性好、可以实现高可靠高并发部署、具有负载均衡能力。

委托的定义 什么是委托？ 委托实际上是一种类型，是一种引用类型。 微软用delegate关键字来声明委托，delegate与int，string，double等关键字一样。都是声明用的。 下面先看下声明代码，这里声明了两个委托。 1 2 public delegate void TestDelegate(string message); public delegate int TestDelegate(MyType m, long num); delegate既然是关键字，和int，string一样，那么，为什么delegate后又跟了一个void或者int呢？ 如果他们是同等地位的关键字，为什么可以一起使用呢？ 很简单，我们把delegate后面的 【void TestDelegate(string message)】理解为一个变量，是不是就清晰明了了一些。 我们把delegate关键字理解为，是用来专门来定义这种复杂的变量的。而这种复杂的变量可以包含一个返回值和任意数目任意类型的传入参数。 有没有感觉，这个复杂的变量特别像一个函数的定义。 没错，官方定义，委托类型的声明与方法签名相似。所以，这个复杂变量，的确，书写的方式就是与函数一样。 那么，为什么这个声明方式如此怪异呢，是因为，我们用delegate定义的变量，只能用函数赋值。赋值方式如下所示： 1 2 3 4 5 6 7

如何理解多租户架构？ 引用： https://www.cnblogs.com/pingfan21/p/7478242.html 　　 前段时间公司产品进行了架构的进化，进化到了多租户架构。当我第一次听到多租户时，我也挺纳闷，不理解。但当我逐渐的翻阅资料，以及研发功能时。不断的加深了对多租户的理解。尽管我现在也只是浅浅的懂一点而已。 　　OK,Let's get this straight（让我们搞懂它），接下来让我们问自己几个问题: 　　1.什么是多租户架构？ 　　2.多租户架构的优缺点？ 　　3.多租户架构的适用场景？ 　　让我们带着这几个问题进入下面的阅读。 一、对多租户的理解 　　多租户定义：多租户技术或称多重租赁技术，简称SaaS，是 一种软件架构技术 ，是实现如何在 多用户环境下（此处的多用户一般是面向企业用户）共用相同的系统或程序组件 ，并且可 确保各用户间数据的隔离性 。简单讲：在一台服务器上运行单个应用实例，它为多个租户（客户）提供服务。从定义中我们可以理解：多租户是一种架构，目的是为了让多用户环境下使用同一套程序，且保证用户间数据隔离。那么重点就很浅显易懂了， 多租户的重点就是同一套程序下实现多用户数据的隔离 。对于实现方式，我们下面会讨论到。 　　在了解详细一点：在一个多租户的结构下，应用都是运行在同样的或者是一组服务器下，这种结构被称为“单实例”架构

本系列七篇文章列表如下： 微服务实战（一）：微服务架构的优势与不足 微服务实战（二）：使用API Gateway 微服务实战（三）：深入微服务架构的进程间通信 微服务实战（四）：服务发现的可行方案以及实践案例 微服务实践（五）：微服务的事件驱动数据管理 微服务实践（六）：选择微服务部署策略 微服务实践（七）：从单体式架构迁移到微服务架构 【编者的话】这篇博客是用微服务建应用的第六篇， 第一篇 介绍了微服务架构模板，并且讨论了使用微服务的优缺点。随后的文章讨论了微服务不同方面：使用API网关，进程间通讯，服务发现和事件驱动数据管理。这篇文章，我们将讨论部署微服务的策略。 部署一个单体式应用意味运行大型应用的多个副本，典型的提供若干个（N）服务器（物理或者虚拟），运行若干个（M）个应用实例。部署单体式应用不会很直接，但是肯定比部署微服务应用简单些。 一个微服务应用由上百个服务构成，服务可以采用不同语言和框架分别写就。每个服务都是一个单一应用，可以有自己的部署、资源、扩展和监控需求。例如，可以根据服务需求运行若干个服务实例，除此之外，每个实例必须有自己的CPU，内存和I/O资源。尽管很复杂，但是更挑战的是服务部署必须快速、可靠和性价比高。 有一些微服务部署的模式，先讨论一下每个主机多服务实例的模式。 单主机多服务实例模式 部署微服务的一种方法就是单主机多服务实例模式，使用这种模式

1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、 腾讯 、 360 、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有 Dubbo 、 SpringCloud 、 thrift 、 grpc 等。 2 微服务落地存在的问题 虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面： 1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。 2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。 3）微服务数量众多，其测试、部署、监控等都变的更加困难。 随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用。对于第三个问题，随着docker

文章目录 《微服务架构实战》读书笔记四----Docker Docker原理 更轻量级的虚拟化 三个概念理解Docker Dockerfile 定制一切 Dockerfile命令 Dockerfile构建过程 《微服务架构实战》读书笔记四----Docker Docker原理 Docker是一个客户端-服务端(C/S)架构的程序，Docker客户端只需要向Docker服务端或守护进程发出请求，服务器或守护进程将完成所有工作并返回结果。Docker提供了一个命令行工具Docker及一整套RESTful API 可以在同一台宿主机器上运行Docker守护进程和客户端，也可以从本地的Docker客户端连接到运行在另一台宿主机远程的Docker守护进程 Docker依赖的Linux的内核特性包括Namespaces命名空间和Control groups控制组。 Namespace命名空间 PID 进程ID隔离 NET 管理网络端口 IPC 进程间通信 管理跨进程通信的访问 MNT 管理挂载点 UTS 隔离内核和版本标识 Control groups 控制组 Control groups控制组 资源限制 优先级设定 资源度量 资源控制及资源分配 Docker 容器的能力包括 文件系统隔离----每个容器都在自己的root文件系统，可以独立挂载外部文件系统 进程隔离---

据报告显示到 2025 年，全球将产生 180ZB 的数据。这些海量的数据正是企业进行数字化转型的核心生产因素，然而真正被有效存储、使用和分析的数据不到百分之十。如何从 ZB 级的数据中寻找分析有价值的信息并回馈到业务发展才是关键。11 月 30 日 UCan 技术沙龙大数据专场（北京站）邀请了 5 位资深大数据技术专家分享他们对大数据的探索和应用实践。 大数据业务常态化的处理手段与架构衍变 很多开发人员在解决实际的业务问题时，经常会面临如何选择大数据框架的困惑。比如有十亿条数据需要进行聚合操作，是把数据放在 HBase+Phoenix 还是 Kudu+Impala 或是 Spark 上进行呢？到底哪种方案才能够达到降低开发运营成本且性能足够高的效果呢？ UCloud 大数据工程师刘景泽分享了他的思考。 要想对数据进行分析决策，首先要有数据来源，其次要将采集到的数据进行存储，然后把这些数据进行汇总、聚合、计算，最后反馈到数据应用层。目前市面上主流的大数据框架有几百种，总结下来主要分为数据采集层、数据存储层、数据计算层和数据应用层。除此之外，一套完整的大数据技术栈还包括了任务调度、集群监控、权限管理和元数据管理。 面对数量众多、种类繁杂的技术栈，选择的自由度很高，但前提是不能把强依赖的框架给拆分开。这里刘景泽给出了一个通用型架构如下图所示： 图中左边 OLTP SDK 指的是后台接口

作者丨张瓅玶（谷朴）阿里巴巴研究员 阿里巴巴核心系统作为全球最大规模、峰值性能要求最高的电商交易系统，在 2018 年之前只通过混合云弹性上云方式，为 双11 节约大量成本。直到 2019 年，阿里巴巴实现了核心交易系统全面上云并经历了 双11 峰值的考验。 在今天由极客邦科技举办的 ArchSummit 全球架构师峰会 2019 北京站上，阿里巴巴研究员张瓅玶博士作了主题演讲《阿里巴巴核心系统上云：挑战和架构演进的思考》，以下内容为演讲整理。 核心系统上云之路 工程师时常把我们的系统用飞机来做比喻，乘客则是上面承载的业务。云也是一架这样的载客飞机，作为基础平台承载着千万家企业的业务。今年阿里巴巴实现了核心系统 100% 上云，这个过程实际上走了几年才达到今天的进展，而且这还不是结束，也只是阿里巴巴上云的一个开始。 阿里巴巴集团自身业务体量巨大，支撑其的互联网技术体系任务也非常繁重，再加上核心电商业务系统的复杂度，对技术带来的挑战可想而知。 用王坚博士的话说，核心系统上云让阿里巴巴和客户真正坐上了同一架飞机。从 in-house 的基础设施、定制化的平台能力，到通用的云平台，从 cloud hosting 到 cloud native，这个过程面临着巨大的挑战，同时也是阿里巴巴自身和阿里云的架构演进升级的历程。 阿里巴巴的核心交易系统涉及到包括天猫、淘宝、河马、菜鸟、聚划算、咸鱼

作者丨张瓅玶（谷朴）阿里巴巴研究员 阿里巴巴核心系统作为全球最大规模、峰值性能要求最高的电商交易系统，在 2018 年之前只通过混合云弹性上云方式，为 双11 节约大量成本。直到 2019 年，阿里巴巴实现了核心交易系统全面上云并经历了 双11 峰值的考验。 在今天由极客邦科技举办的 ArchSummit 全球架构师峰会 2019 北京站上，阿里巴巴研究员张瓅玶博士作了主题演讲《阿里巴巴核心系统上云：挑战和架构演进的思考》，以下内容为演讲整理。 核心系统上云之路 工程师时常把我们的系统用飞机来做比喻，乘客则是上面承载的业务。云也是一架这样的载客飞机，作为基础平台承载着千万家企业的业务。今年阿里巴巴实现了核心系统 100% 上云，这个过程实际上走了几年才达到今天的进展，而且这还不是结束，也只是阿里巴巴上云的一个开始。 阿里巴巴集团自身业务体量巨大，支撑其的互联网技术体系任务也非常繁重，再加上核心电商业务系统的复杂度，对技术带来的挑战可想而知。 用王坚博士的话说，核心系统上云让阿里巴巴和客户真正坐上了同一架飞机。从 in-house 的基础设施、定制化的平台能力，到通用的云平台，从 cloud hosting 到 cloud native，这个过程面临着巨大的挑战，同时也是阿里巴巴自身和阿里云的架构演进升级的历程。 阿里巴巴的核心交易系统涉及到包括天猫、淘宝、河马、菜鸟、聚划算、咸鱼

作者丨张瓅玶（谷朴）阿里巴巴研究员 阿里巴巴核心系统作为全球最大规模、峰值性能要求最高的电商交易系统，在 2018 年之前只通过混合云弹性上云方式，为 双11 节约大量成本。直到 2019 年，阿里巴巴实现了核心交易系统全面上云并经历了 双11 峰值的考验。 在今天由极客邦科技举办的 ArchSummit 全球架构师峰会 2019 北京站上，阿里巴巴研究员张瓅玶博士作了主题演讲《阿里巴巴核心系统上云：挑战和架构演进的思考》，以下内容为演讲整理。 核心系统上云之路 工程师时常把我们的系统用飞机来做比喻，乘客则是上面承载的业务。云也是一架这样的载客飞机，作为基础平台承载着千万家企业的业务。今年阿里巴巴实现了核心系统 100% 上云，这个过程实际上走了几年才达到今天的进展，而且这还不是结束，也只是阿里巴巴上云的一个开始。 阿里巴巴集团自身业务体量巨大，支撑其的互联网技术体系任务也非常繁重，再加上核心电商业务系统的复杂度，对技术带来的挑战可想而知。 用王坚博士的话说，核心系统上云让阿里巴巴和客户真正坐上了同一架飞机。从 in-house 的基础设施、定制化的平台能力，到通用的云平台，从 cloud hosting 到 cloud native，这个过程面临着巨大的挑战，同时也是阿里巴巴自身和阿里云的架构演进升级的历程。 阿里巴巴的核心交易系统涉及到包括天猫、淘宝、河马、菜鸟、聚划算、咸鱼