公司新版架构设计

1、 应用、数据库、文件都在一台机子上 使用免费开源的软件为主 操作系统无要求（一般是Linux）初始阶段的小应用 三台服务器分别存放应用程序、非结构化数据、结构化数据 数据库服务器独立部署使之能占用更多CPU、内存、硬盘 文件服务器独立部署使之能够占用更多磁盘空间应用服务与数据服务分离 缓存分类：本地缓存、远程缓存 本地缓存快，受单机缓存容量限制缓存内容少；不利于分布式应用架构 远程缓存有网络损耗、容量大、扩展性高使用缓存改善应用性能 应用服务器处理请求连接有限、存在瓶颈 提升单一服务器性能花费巨大、扩展能力有限、存在瓶颈 通过增加更多服务器、提升请求处理能力、可伸缩 应用服务器集群是可伸缩集群

2、架构设计中较为简单和成熟的一种 利用负载均衡调度服务器，实现按需请求分发 负载均衡调度可以是软件级、硬件级、网络级应用服务器集群提升并发处理能力 存在不能缓存的情况多，数据库写入也不少的情况下，数据库负载压力成为网站瓶颈 利用热备功能，配置主-从关系，实现读写分离，分担单一节点的数据压力 利用独立数据库访问模块，实现读写分离调度，对用于透明 读写分离调度模块可以是独立硬件，也可以是调度程序 主-从复制基于时间调度（简单但不够实时）或事件调度（复杂但相对精准）数据库读写分离 中国网络环境复杂，不同地域访问速度存在差异 单一网络节点无法“公平”的提供一直的访问质量 利用CDN及反向代理机制，缓存静

3、态数据 为用户请求分派距离最近的网络服务点 减轻服务核心支撑点的访问压力反向代理和CDN加速 集中式存储文（文件、数据）无法满足庞大数据量环境 分布式数据库是数据库拆分得最后手段，只有单表数据规模非常大的时候才使用 应用更常用的数据库分拆手段是业务分库 分布式数据库及文件架构，就应用程序而言不透明 一般需要与集群式、分布式架构中作出权限后才决定方案分布式文件存储和分布式数据库 数据存储和检索需求越来越复杂 传统关系型技术无法满足需求（存储、速度） 数据交换能力大大提升 一般会涉及集群架构 对持久化、ACD需要有折冲使用NOSQL和搜索引擎 大型应用业务场景复杂，需要分而治之的解决不同业务问题

4、根据业务划分不同产品线及板块，由不同业务团队负责，并最终提供不同服务 不同应用独立部署，通过链接，消息队列、接口服务进行交互通讯，最多的是通过共享存储来实现关联 性能减弱、可用性提升、维护容易，项目更简单业务拆分 存储系统越来越庞大，整体复杂度指数级增长 部署维护困难 资源链接是服务器规模的平方，出现链接资源不足分布式服务高性能高性能够敏捷够敏捷项目架项目架构目标构目标高可用高可用可伸缩可伸缩够安全够安全易扩展易扩展项目架构模式敏捷分层分割分布集群缓存异步冗余安全自动现有的大部分工具、应用服务器、框架和脚本都是这种应用程序像NetBeans、Eclipse、IntelliJ这些开发环境都是针对

5、开发、部署、调试这样的单个应用而设计的单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始只需将单个归档文件复制到单个目录下对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题

6、会显得尤为严重对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具，无法根据具体的场景做出其它选择“不坏不修（Not broken，dont fix）”，这在软件开发中非常常见，单体应用尤其如此。系统设计或写好的代码难以修改，因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭，这必然会增加应用程序的技术债务传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系

7、统扩展，而不能针对某一个功能模块进行扩展传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的

8、工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C+来编写一个实时聊天组件更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务使用微服务架构后，开发团队需要保证一个集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整在很多

9、服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟用户层应用体系层数据支撑层数据接入层普通用户 医总管平台（签约转诊）IPTV平台养老平台儿童身高管理平