认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习计算机编程开发技术，今天北京达内小编就带大家了解下分布式编程开发都有哪些注意事项。

分布式系统是指多个物理硬件设备与单独的离散用户交互并通过这些硬件设备协作以为这些离散的单独用户实现不同且相似的目标。 有时，这些设备使用服务器作为集线器以点对点模式工作，以了解彼此之间的连通性，而其他设备则通过单个或一组集中式服务器进行协作和协调。

分布式系统可以是原生的，也可是对现有的集中式系统的垂直或者水平的拆分。拆分的目标通常是从性能角度考虑。分布式的系统有更好的伸缩性，能更充分利用硬件。现在的IT平台，硬件是低成本的，容易获取的，但软件系统开发和维护是高成本的，特别是在大并发海量数据的条件下，运维的难度是很高的。如果能做出一些合理而不是过度的拆分，那对解决问题很有意义的。

服务打包在一个实例里运行，就是集中式服务，把服务拆分到不同的实例在不同的硬件在运行，就是分布式服务。比如微服务是一种分布式服务。把缓存从实例中拆分出来用独立的缓存服务器实现，就是分布式缓存。从队列从实例的内存中拿出来，用独立的消息中间件部署在独立的硬件上实现，就是分布式队列。分布式的关键是“分”，是一种为了解决各种问题而进行的一种拆分动作。一个数据库要执行SQL现在可以在多个数据库上执行SQL就是分布式数据库。

要警惕过度拆分。拆分不是越细越好，而是合理拆分，甚至是最小化拆分（拆分的越少越好，能不拆分就不拆分），以解决问题为目标。拆分意味着复杂度，过度拆分会使系统之间的分布式调用异常复杂。分布式的服务调用相对于实例内的调用完全不是一回事。一个进程内的调用不存在网络通信，都是共享内存，事务也是同一个。但是分布式意味着网络可能中断，服务可能不可能用，数据可能不一致等等，甚至会出现多个服务来回调用出现死锁的极端状况。如果在对数据库在进行分布式设计，那复杂度又要提升一个量级，数据如何分布，数据如何在分布式模型下存取，各种一致性如何保证，各种报表如何支持等等一系列的问题需要处理。这种复杂度体现在开发层面，测试层面，运维层面等多个层面。

要设计好分布式系统，可以按这样的思路来设计：

分布式的设计首先要明确目标，到底要解决什么问题，哪些问题是真正的问题？拆分通常需要一定的工作量，所以一定是为了解决真正的问题去做，而不是为了拆而拆。如果应用层的问题那么应用的瓶颈在哪里？是不是可以把瓶颈拆分出来，或者是否提供一个框架把瓶颈按需拆分？如果数据库是瓶颈，那么是不是可以利用数据库的扩展能力解决？比如，物化，冗余，集群，归档，读写分离等等。设计分布式业务模型是没有办法的办法。

明确目标是最重要的一步，绝对不能为了分而分。

明确目标后，就要设计系统的“静态”模型。这时候不用过多的考虑实现细节，要设计一个能解决问题的静态模型。如果拆分部署，那么要画出一个拆分后服务的静态模型。模型里体现哪些服务拆分，服务之间的调用关系。如果是数据拆分，那就要给出一个拆分之后的静态的业务模型。我认为，静态模型是架构设计里面至关重要的部分。静态的能实现目标，通常问题就解决了一大半。

静态模型基本完成后，可以构造“动态模型”，也就是要进行业务场景推演和扩展推演，异常推演，看看核心业务场景在这个静态模型下如何实现，性能出现瓶颈在这个模型怎么扩展，出现异常（比如一致性，系统宕机等）情况如何处理等。在推演的过程就要在给出各种辅助的工具，公共组件，规范。这个阶段不需要给出工具，组件，规范的具体细节，只需描述其功能即可。构造动态模型的过程，可能会对静态模型进行修正，动态模型是设计中最接近落地的一步，这一步会对落地难度有足够的评估。 必要的话，要做一些测试来做方案验证。试错，最好在动态模型这个阶段来试错，一旦系统落地在出错，那成本和风险就要高很多。

推演和针对性的测试 是一种试错，这个做的越是充分，风险越小。

当动态模型推演结束后，可以对规划出来的组件，规范，工具进行详细的设计。这个阶段风险就不大了。

监控的设计是至关重要的一步。分布式系统特别线上系统，监控是系统成功的基石。监控可以认为是对静态模型和动态模型的可视化。把这个过程和结果可视化，数字化，让运维人员随时了解系统的性能状态，问题点，业务操作的情况，数据的分布等等，并及时做出相应的动作或者反馈给研发做出产品改进。监控不仅仅保证系统可用性同时也是实现产品闭环的重要环节。

“分布式编程开发都有哪些注意事项？”看了以上北京达内小编为您梳理的，相信您应该有所了解了，想要了解更多北京分布式编程开发相关问题，可以咨询下方图片咨询老师为您安排解答呦！