spring-cloud 的一些心得体会

​ 在程序发展的初期，相关的程序比较的简单，而且那时候计算机的普及程度并不是很高，我们只需要用一台计算机就可以应付大部分的情况，但是后来随着计算机的快速发展，之前的设备或者程序已经完全不能支撑日益上升的相关的访问需求，那个时候我们大概有数种解决办法，但是最直接的就是更换更加昂贵的设备或者改变相关的软件服务架构。当软件在慢慢的变复杂，开发和运维成本也在随之上升，这也是在软件开发发展过程中，改变或升级架构的一个原因，降低软件的复杂度，而降低软件复杂度的的大部分办法是对项目结构进行拆分，将一个模块拆分成数个模块，这样相关的软件复杂度和耦合度也下降了，程序进入了相对健康的发展阶段. 我们都知道，在一个相关的程序里，各个模块的请求量是不同的，有的模块访问量可能会比较低，但有的模块的访问量也会相对比较低。比如一个博客系统，它的查询那些博客的业务访问量是比较大的，在一个电商系统里，在平时的业务中，它的支付业务和其他业务是相对比较平稳的，但是在双十一的时候，电商系统的支付业务和相关的业务访问量会以几何倍数激增，在这个时候，企业必然要对访问量激增相关的业务增加更多的设备，以保证相关的业务能够平稳运行。如果这个业务激增的模块没有从原有的软件架构中拆分出来，那必然导致电商系统无法处理激增的访问量。企业将会面临相关的损失。 在服务器中，存在cpu密集型业务和io密集型业务，但是我们的服务器不都是cpu和硬盘都很好的，我们的服务器各有其长，我们应当正确的使用相关的服务器的相关资源，将cpu密集型业务模块映射到CPU比较好的服务器上，将I/O密集型业务模块映射到硬盘比较好的服务器上。 cpu密集型也叫计算密集型，一般是指服务器的硬盘、内存硬件性能相对cpu好很多，或者使用率低很多。系统运行cpu读写i/o(硬盘/内存)时可以在很短的时间内完成，几乎没有阻塞（等待I/O的实时间）时间，而cpu一直有大量运算要处理，因此cpu负载长期过高。   CPU密集几乎无I/O阻塞，CPU一直会全速运行。如果是单核情况下，开多线程是没有意义的，说白了就是一个CPU来回切着运行而已，徒增线程切换的资源消耗，卵用没有。可见，CPU密集任务只有在多核CPU上、开多线程才可能提速。   CPU使用率较高时（如我们训练算法模型、搞训练集），通常线程数只需要设置为CPU核心数的线程个数就可以了。单CPU对应单线程效率最高。 ​ I/O密集型相反，一般是指服务器CPU的性能相对硬盘、内存硬件好很多，或者使用率低很多。系统运行多是CPU在等I/O (硬盘/内存) 的读写操作，此类情景下CPU负载并不高。   I/O密集型的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而程序的逻辑做得并不好，没有充分利用CPU能力，导致​​线程空余时间很多​​​。通常我们会开​​CPU核心数​​数倍的线程，在线程进行 I/O 操作 CPU 空闲时，启用其他线程继续使用 CPU，以提高 CPU 的使用率，充分利用CPU资源。 微服务架构成为新常态的原因就是很好的降低了软件的复杂度，能够充分的利用资源，提升开发速度。将服务拆的足够清楚，在某个服务访问量上升的时候，可以只给这个服务扩容，这就是充分的利用资源，除此之外，也能做到快速集成，我在重新集成这个服务的时候，就不会影响到其他服务，也就是解耦合。但这并不代表微服务是完美无缺的，管理和运维微服务相对于过去就变得有些复杂起来了，这也是Docker等流行的原因。（基本可以认为，微服务架构 根据业务进行模块拆分业务，每个业务单独一个模块，模块单独运行）. 分布式系统强调的是一组计算机，我们如果只有计算机，计算机性能比较好，使用Docker完成部署，是不是也算一种分布式架构呢，这其实并不能算的，假如这个 机器突然断电了怎么办，如果这个机器断电之后，所有的服务是不是立刻就挂掉了，这还怎么向外提供服务你我，我觉得分布式强调一组计算机就是为了强调这种资源备用和强大的容灾机制。那反过来，我们如何在一台服务器挂掉之后还能提供服务呢，我们当然会选择相关的集群部署，就是相同的机器找相同的服务器又部署了几次，当一台服务器出现了问题的时候，有其他的服务器立马切换相关的节点和服务，使得我们的服务还能够继续运行。 如果若干个程序如果部署在若干台不同的计算机上，它们通过网络相互协作最终完成一个服务，那么这些程序组成的系统就可以称为分布式系统。如果是相同的程序,在本机部署了多次，有了Docker后这很轻松，这就叫集中式集群。如果是在不同的计算机上部署了多次，我们可以称之为分布式集群。主要强调的还是的若干个程序和若干台服务器。但是集群部署也不是完美无瑕的，集群部署在解决了集中式部署的相关问题之后，又诞生了相关的其他问题-》CAP（这些诞生出的其他问题的根本原因是网络是不可靠的） 百度百科是这么介绍CAP的 CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：保证每个请求不管成功或者失败都有响应。 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。 [1] CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足 [2] 。 因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的。 CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。 数据库事务一致性需求　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。 数据库的写实时性和读实时性需求　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。 对复杂的SQL查询，特别是多表关联查询的需求　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。 学习Spring-cloud其实就是解决这些相关的问题，将问题模块化，简单化，达到快速迭代的要求。 与分布式系统相关的复杂性– 包括网络问题，延迟开销，带宽问题，安全问题。 处理服务发现的能力– 服务发现允许集群中的进程和服务找到彼此并进行通信。 解决冗余问题– 冗余问题经常发生在分布式系统中。 负载平衡– 改进跨多个计算资源（例如计算机集群，网络链接，中央处理单元）的工作负载分布。 减少性能问题– 减少因各种操作开销导致的性能问题。