应用架构

系统可用率 多级缓存 动态分组切换 DB物理隔离 服务分组隔离 跨机房隔离 漏斗模型 DB限流 系统一般可以分为前端应用系统和后端数据库系统，前端应用系统实施分布式集群部署技术上是比较成熟的，后端数据库系统实现异地多活技术难度很大，目前也只有阿里，京东这样的公司才真正实现。因此，对于大多数应用，前端应用双机房集群部署，后端数据库系统采取成熟的主备从的模式，也就是单个机房作为写入，备库在另外机房，可以快速进行切换，读库双机房部署，是优选的方案。对于这个架构方案，存在跨机房写延长的问题，可以根据场景利用异步的方式进行解决，一般也是没有问题的。对于系统来讲，也有些特别，利用分拣中心的本地服务器和操作人员的设备，实现离线生产，进一步提高可用性。 大系统小做，服务拆分 ，是互联网应用的特点，也符合敏捷交付的理念。对于传统软件，如Windows，Office等，都要经过一个漫长的需求，研发，测试，发布周期，在“唯快不破”的互联网时代，这显然是无法满足业务要求的，即使最后上线，也可能因为周期太长而不再适用了。因此，对一个互联网服务，一般会首先完成最核心的功能，快速进行上线，不断进行迭代，后续再进行辅助功能跟进。对于核心功能，随着用户数的增加，会不断进行服务拆分，如何进行拆分，拆分到什么样的粒度，是不是微服务是解决问题的银弹？这些都要根据实际的应用场景来评估，绝不是越细越好

一、AgileEAS.NET平台简介 AgileEAS.NET平台 是一套应用系统快速开发平台，用于帮助中小软件开发商快速构建自己的企业信息管理类开发团队，以达到节省开发成本、缩短开发时间，快速适应市场变化的目的，AgileEAS.NET应用开发平台包含基础类库、资源管理平台、运行容器、开发辅助工具等四大部分，资源管理平台为敏捷并行开发提供了设计、实现、测试等开发过程的并行。 AgileEAS.NET平台 基于软件过程改进以及构件化快速开发两方面达到这方面的目标，在软件过程改进实践方面，提出了独有的“ 敏捷并行开发方法 ”开发方法，其目的是在软件的管理之中提出符合国内中小软件企业实际情况并且可操作的软件工程实践、软件过程改进思想、及相配套的项目管理系统。 在快速开发方面， AgileEAS.NET平台 平台提供了企业应用开发所需的诸如ORM、IOC、分布式通信、插件与平台基础结构以及一系统的快速生成工具，涵盖开发过程中的设计、编码、集成、部署、运维等各个环节。 二、有关AgileEAS.NET文章汇总 有关于AgileEAS.NET平台介绍的文章 5.0 版本介绍 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - 5.0 简介 4.2重构改进 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - Linq 2 EAS

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、微服务以及分布式数据管理中存在的问题 单体应用通常使用单个关系型数据库，由此带来的好处在于应用能够使用 ACID 事务，后者提供了重要的操作特性： 原子化： 原子粒度的更改 一致性： 数据库的状态始终保持一致 隔离： 并发执行的事务显示为串行执行 持久： 事务一旦提交就不会被撤销 如此，应用能够简单地开始事务、更改（插入、更新和删除）多行、以及提交事务。 使用关系型数据库的另一大好处是它支持 SQL。SQL 是一门丰富、可声明的和标准化的查询预约。用户能够轻松通过查询将多个表中的数据组合起来，然后 RDBMS 查询调度器决定执行查询的最优方法。用户不必关心底层细节，比如如何访问数据库。此外，由于所有的应用数据在一个数据库中，很容易查询。 然而，微服务架构中的数据访问变得复杂许多。每个微服务拥有的数据专门用于该微服务，仅通过其 API 访问。这种数据封装保证了微服务松散耦合，并且可以独立更新。但如果多个服务访问相同数据，架构更新会耗费时间、也需要所有服务的协调更新。 更糟糕的是，不同的微服务通常使用不同类型的数据库。现代应用存储和处理各种类型的数据，而关系型数据库并非总是好选择。对于一些使用场景，特定的 NoSQL 数据库能提供更方便的数据模型、更好的性能和可扩展性。譬如，服务使用 Elasticsearch

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本系列七篇文章列表如下： 微服务实战（一）：微服务架构的优势与不足 微服务实战（二）：使用API Gateway 微服务实战（三）：深入微服务架构的进程间通信 微服务实战（四）：服务发现的可行方案以及实践案例 微服务实践（五）：微服务的事件驱动数据管理 微服务实践（六）：选择微服务部署策略 微服务实践（七）：从单体式架构迁移到微服务架构 【编者的话】本文是使用微服务创建应用系列的第五篇文章。第一篇文章介绍了微服务架构模式，并且讨论了使用微服务的优缺点；第二和第三篇描述了微服务架构模块间通讯的不同方面；第四篇研究了服务发现中的问题。本篇中，我们从另外一个角度研究一下微服务架构带来的分布式数据管理问题。 1.1 微服务和分布式数据管理问题 单体式应用一般都会有一个关系型数据库，由此带来的好处是应用可以使用 ACID transactions，可以带来一些重要的操作特性： 原子性 – 任何改变都是原子性的 一致性 – 数据库状态一直是一致性的 隔离性 – 即使交易并发执行，看起来也是串行的 Durable – 一旦交易提交了就不可回滚 鉴于以上特性，应用可以简化为：开始一个交易，改变（插入，删除，更新）很多行，然后提交这些交易。 使用关系型数据库带来另外一个优势在于提供SQL（功能强大，可声明的，表转化的查询语言

前言：SSO 单点登录 　　“半吊子”的全栈工程师又来了，技术类的文章才发表了两篇，本来想先将主攻的几个系列都开个头（Nodejs、Java、前端、架构、全栈等等），无奈博客起步太晚，写博文的时间又没有很多，只好不按顺序乱发一通，请大家见谅。 　　本篇文章介绍一下单点登录，不像上一篇博文介绍的前后端分离，SSO 并不能算是一种架构吧，只能说是一个解决方案。由于笔者参与过医院集成平台项目，负责其中单点登录的设计研发工作，将经验总结分享一下，也不一定是最优方案，正确与否那就“仁者见仁智者见智”了。 　　单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，即用户只需要记住一组用户名和密码就可以登录所有有权限的系统。 　　文章导读：开篇先介绍一下笔者从事医疗行业出现单点登录的项目需求，毕竟是需求驱动研发；再将整理的通用版的单点登录知识进行分享；接着介绍一下笔者当前采用集成平台单点登录方案，最后是一些相关扩展。 单点登录背景介绍 　　 【医疗行业的需求】 　　 　　随着医院信息化建设的深入，信息化系统越来越多，五花八门多种多样，初步统计目前医院信息化子系统数量已经多达几十个。这些系统的安装维护不仅让信息中心花费大量心血，也让多角色的用户在使用系统时头疼不已

1. SOA与微服务 　　面向服务（SOA）已经不是一个新名词了，跟Paxos有一样古老的年龄，其本质是一种软件架构的设计思想。类似“云计算”的分层和服务提供概念（IaaS==>PaaS==>SaaS），SOA是把企业应用的业务功能以能力开放的形式提供出来，比如通过构建企业服务总线ESB来实现企业应用间的服务集成和编排。 而微服务更多的是对SOA的一种实践方式（ESB也是SOA的一种实现方式），主要针对企业应用系统本身的架构设计做解耦和组件服务化，从业务上把原来庞大的系统拆分为多个可以独立设计、独立开发、独立部署的小应用，小应用之间通过特定的交互协议（RPC/HTTP等）完成服务的暴露和调用。 　　关键词：组件服务化，去中心化，分布式，自动化部署和发布 2. 微服务与传统集群 　　传统集群的常见架构一般是前端做负载均衡（F5、apache、nginx）反向代理一堆Web容器中的war，通常一个war就是整个应用（把整个应用放在一个进程中），后端再接统一的缓存和DB等等。 而微服务的一种可能设计是前端做负载均衡，请求代理到控制层后调用部署在不同机器上的小应用来共同完成一次请求，小应用之间也会有相互的依赖调用，各个小应用本身可以有自己的缓存和DB，也可以多个小应用共用同一个持久层。 　　网上的一个对比图：左边是传统集群，右边是微服务，可以看到一个微服务的小应用就是一个进程

应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开发最复杂，变化最多的地方，优化手段主要有缓存、集群和异步等。 分布式缓存 　　缓存无处不在，既存在于浏览器、也存在于服务器和数据库；既可以对数据缓存，也可以对文件缓存，还可以对页面片段进行缓存。 　　网站性能优化第一定律：优先考虑使用缓存优化性能。 缓存的基本原理 　　缓存是指将数据存储在相对较高访问速度的存储介质中。一方面缓存访问熟读快，可以减少访问时间；另一方面如果缓存的数据是经过计算处理得到的，那么被缓存的数据无需重复计算即可直接使用，因此缓存还可以减少计算时间。 缓存的本质是一个内存HASH表，网站应用中，数据缓存以一对Key、Value的形式存储在Hash表中。缓存主要用来存放读写频率比较高、很少变化的数据。应用程序读取数据时，先到缓存中读取，先到缓存中读取，如果读取不到或数据已经失效，再访问数据库，并将数据写入缓存。 　　2.合理使用缓存 使用缓存对提高系统性能有很多好处，但是不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。 　　 频繁修改的数据 ：如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效，徒增系统负担，还可能读取到脏数据。 　　 没有热点的访问: 缓存使用内存作为存储，如果应用程序访问数据没有热点，那么缓存就没有意义。 　　

软件架构 设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。本文从 架构师职责、 软件架构定义、设计架构、评估架构、架构管理 等方面来描述了解软件架构的含义和怎样设计软件架构。 一、软件架构师的职责 架构师分为以下几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（ J2EE 架构师、 .NET 架构师等）、系统架构师。 1 、架构师的职责主要体现 架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面： 1 ）、负责公司系统的架构设计、研发工作。 2 ）、承担从业务向技术转换的桥梁作用。 3 ）、协助项目经理制定项目计划和控制项目进度。 4 ）、负责辅助并指导系统分析开展设计工作。 5 ）、负责组织技术研究和攻关工作。 6 ）、负责组织和管理公司内部的技术培训工作。 7 ）、负责组织及带领公司内部员工研究与项目相关的新技术。 8 ）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。 9 ）、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。 10 ）、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。 2 、构架设计师必须具备的技能 经验：既包括在问题领域的经验

1. YARN产生背景 MapReduce本身存在着一些问题： 1）JobTracker单点故障问题；如果Hadoop集群的JobTracker挂掉，则整个分布式集群都不能使用了。 2）JobTracker承受的访问压力大，影响系统的扩展性。 3）不支持MapReduce之外的计算框架，比如Storm、Spark、Flink等。 与旧MapReduce相比，YARN采用了一种分层的集群框架，具有以下几种优势。 1）Hadoop2.0提出了HDFSFederation；它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展。对于运行中NameNode的单点故障，通过 NameNode热备方案（NameNode HA）实现 。 2） YARN通过将资源管理和应用程序管理两部分剥离开来，分别由ResourceManager和ApplicationMaster进程来实现。其中，ResouceManager专管资源管理和调度，而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等。 3）YARN具有向后兼容性，用户在MR1上运行的作业，无需任何修改即可运行在YARN之上。 4）对于资源的表示以内存为单位（在目前版本的 Yarn 中没有考虑 CPU的占用），比之前以剩余 slot 数目为单位更合理。 5）支持多个框架，YARN不再是一个单纯的计算框架

REST是所有Web应用都应该遵守的架构设计指导原则。 Representational State Transfer，翻译是”表现层状态转化”。 面向资源是REST最明显的特征，对于同一个资源的一组不同的操作。资源是服务器上一个可命名的抽象概念，资源是以名词为核心来组织的，首先关注的是名词。REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。（7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS） 什么是RESTful API？ 符合REST架构设计的API。 总结 符合REST设计标准的API，即RESTful API。REST架构设计，遵循的各项标准和准则，就是HTTP协议的表现，换句话说，HTTP协议就是属于REST架构的设计模式。比如，无状态，请求-响应。。。 参考： 理解本身的REST架构风格 http://www.infoq.com/cn/articles/understanding-restful-style/ 理解RESTful架构 http://www.ruanyifeng.com/blog/2011/09/restful.html Restful API设计指南 http://www.ruanyifeng.com/blog/2014/05/restful_api.html 二