系统架构,什么是分布式系统架构

系统架构，什么是分布式系统架构？

就是将多软件架构设计分散开来，运行在多个服务器上。

分布式系统架构具有心跳包和租约机制功能，能定期监测系统是否存在故障，而即使出现故障整个系统也不会被宕掉。

做一个系统架构师？

具备能力： 作为软件开发的设计架构师，那么必须拥有一定的编程技能，同时有高超的学习新的架构设计、程序设计技能。另外，我觉得作为软件架构师，还必须了解一定的硬件、网络、服务器的基本知识。要不然，你都不知道有些什么材料可以用，你怎么去根据实际情况去规划你的软件架构呢？忽视程序设计能力的持续跟新，是永远不能够成为一个成功的系统架构师。 一般来讲，系统架构师应该拥有以下几方面的能力： 1：具备 8 年以上软件行业工作经验； 2：具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验； 3：具备 3 年以上的代码编写工作经验； 4：具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验； 5：对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握； 6：对 .Net/JAVA 技 术 及 整 个 解 决 方 案 有 深 刻 的 理 解 及 熟 练 的 应 用 ， 并 且 精 通WebService/J2EE 架构和设计模式，并在此基础上设计产品框架； 7：具有面向对象分析、设计、开发能力（OOA、OOD、OOP），精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发； 8：精通大型数据库如 Oracle、Sql Server 等的开发； 9：对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础； 10：在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例； 11：良好的团队意识和协作精神，有较强的内外沟通能力。

支撑百万连接的系统应该如何设计其高并发架构？

首先要结合具体的业务场景，不根据业务就云设计就是在耍流氓。

业务场景

首先你要确定你所架构的系统服务于什么业务。假如我们现在是一个小创业公司，注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。但是你要考虑到后面注册用户数达到了2000万！每天活跃用户数100万！每天单表新增数据量达到50万条！高峰期每秒请求量达到1万。

静态资源

大宽带、CDN、缓存（页面缓存、对象缓存），WEB服务器缓存等N级分布式缓存，Redis、Memcached缓存集群。

动态资源

计算：多组服务器，负载均衡等技术控制流量。

存储：存储这里就比较麻烦，按照KV存储简单的资源，然后在计算部分进行整合。真的没办法做KV的，采用跨库索引来做。单机存储数量要合理，不能太多。还有就是事务性的问题，解决方案就是BASE思想或者采用日志方式。

纵向拆分、水平扩展

系统按照模块功能纵向拆分，再水平扩展，抽象服务层利用各种中间件完善，优化JVM应用服务器。

消息中间件

用mq解决稳定性。将耗时比较长或者耗费资源的请求排队，异步处理，减轻服务器压力增加稳定性

数据库

关系型、非关系型数据库上最牛比SSD硬盘，分库分表，读写分离，读的流量多时还要增加从库提高IO性能。每秒1万请求到5台数据库上，每台数据库就承载每秒2000的请求，相应的压力也就会减少。

SQL语句避免跨表查询，优化好存储过程，此时注意存储过程利用好了是把利剑，利用不好就成为了累赘。

负载均衡

负载均衡由多种实现方式，一种是在硬件上的，常用软件由F5、NetScaler、Radware和Array等商用的，但是价格较昂贵。另外一种就是软件的，常见的软件有LVS、Nginx、Apache等,它们是基于Linux系统并且开源的负载均衡策略。

简单架构图结语

系统架构中需要注意的点太多，具体业务也不尽相同。实现方案也有多种，此处只提供一个思路。

码字不宜，如果对您有所帮助请点击一个小赞。

系统架构如何进行性能优化？

对于业务系统的性能优化，我原来系统的谈过分析和诊断的思路，今天再谈下业务系统性能优化里面我们常见的一些思考和分析系统性能问题的方法。

上线前的性能测试是否有用？

有时候大家可能觉得奇怪，为何我们系统再上线前都做了性能测试，为何上线后还是会出现系统性能问题。那么我们可以考虑下实际上我们上线前性能测试可能存在的一些无法真实模拟生产环境的地方，具体为：

1. 硬件能否完全模拟真实环境？最好的性能测试往往是直接在搭建完成的生产环境进行。

2. 数据量能否模拟实际场景？真实场景往往是多个业务表都已经存在大数据量的积累而非空表。

3. 并发能否模拟真实场景？一个是并发需要录制复合业务场景，一个是并发量大时候需要多台压测机。

而实际上我们在做性能测试的时候以上几个点都很难真正做到，因此要想完全模拟出生产真实环境是相当困难的，这也导致了很多性能问题是在真正上线后才发现。

系统本身水平弹性扩展是否完全解决性能问题？

第二个点也是我们经常谈的比较多的点，就是我们的业务系统在进行架构设计的时候，特别是面对非功能性需求，我们都会谈到系统本身的数据库，中间件都采用了集群技术，能够做到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题？

实际上我们看到对于数据库往往很难真正做到无限的弹性水平扩展，即使对于Oracle RAC集群往往也是最多扩展到单点的2到3倍性能。对于应用集群往往可以做到弹性水平扩展，当前技术也比较成熟。

当中间件能够做到完全弹性扩展的时候，实际上仍然可能存在性能问题，即随着我们系统的运行和业务数据量的不断积累增值。实际上你可以看到往往非并发状态下的单用户访问本身就很慢，而不是说并发上来后满。因此也是我们常说的要给点，即：

单点访问性能正常的时候可以扩展集群来应对大并发状态下的同时访问

单点访问本身性能就有问题的时候，要优先优化单节点访问性能

业务系统性能诊断的分类

对于业务系统性能诊断，如果从静态角度我们可以考虑从以下三个方面进行分类

操作系统和存储层面中间件层面（包括了数据库，应用服务器中间件）软件层面（包括了数据库SQL和存储过程，逻辑层，前端展现层等）

那么一个业务系统应用功能出现问题了，我们当然也可以从动态层面来看实际一个应用请求从调用开始究竟经过了哪些代码和硬件基础设施，通过分段方法来定位和查询问题。

比如我们常见的就是一个查询功能如果出现问题了，首先就是找到这个查询功能对应的SQL语句在后台查询是否很慢，如果这个SQL本身就慢，那么就要优化优化SQL语句。如果SQL本身快但是查询慢，那就要看下是否是前端性能问题或者集群问题等。

软件代码的问题往往是最不能忽视的一个性能问题点

对于业务系统性能问题，我们经常想到的就是要扩展数据库的硬件性能，比如扩展CPU和内存，扩展集群，但是实际上可以看到很多应用的性能问题并不是硬件性能导致的，而是由于软件代码性能引起的。对于软件代码常见的性能问题我在以往的博客文章里面也谈过到，比较典型的包括了。

1. 循环中初始化大的结构对象，数据库连接等

2. 资源不释放导致的内存泄露等

3. 没有基于场景需求来适度通过缓存等方式提升性能

4. 长周期事务处理耗费资源

5. 处理某一个业务场景或问题的时候，没有选择最优的数据结构或算法

以上都是常见的一些软件代码性能问题点，而这些往往需要通过我们进行Code Review或代码评审的方式才能够发现出来。因此如果要做全面的性能优化，对于软件代码的性能问题排查是必须的。

通过IT资源监控或APM应用工具来发现性能问题

对于性能问题的发现一般有两条路径，一个就是通过我们IT资源的监控，APM的性能监控和预警来提前发现性能问题，一个是通过业务用户在使用过程中的反馈来发现性能问题。

而随着DevOps和自动化运维的思路推进，我们更加希望是通过APM等工具主动监控来发现性能问题，对于APM工具最大的好处就是可以进行服务链间和全链路的性能分析，方便我们发现性能问题究竟发生在哪里。比如我们提交一个表单很慢，通过APM分析我们很容易发现究竟是调用哪个业务服务慢，或者是处理哪个SQL语句慢。这样可以极大的提升我们性能问题分析诊断的效率。

ECU系统架构？

当发动机起动时，电控单元进入工作状态，某些程序和步骤从ROM中取出，进入CPU。这些程序可以是控制点火时刻、控制汽油喷射、控制怠速等。通过CPU的控制，一个个指令逐个地进行循环。执行程序中所需的发动机信息，来自各个传感器。从传感器来的信号，首先进入输入回路，对其信号进行处理。

如是数字信号，根据CPU的安排，经I/O接口，直接进入微机。

如是模拟信号，还要经过A/D转换器，转换成数字信号后，才能经I/O接口进入微机。

大多数信息，暂存在RAM内，根据指令再从RAM送至CPU。