有多少互联网系统确实需要使用分布式架构？

莫说互联网实战开发，现在就连面试应届生的时候，分布式方面的问题都基本是必出的了。

分布式架构简介

以最简单的架构来说，分布式可以通过部署多个功能相近的服务器节点来实现。在实际应用中，只暴露出一个域名给用户，该域名地址通常对应的是一个Nginx，用于负载均衡。Nginx在收到请求后，会根据当前情况，将请求分配给不同的服务器节点来响应。这套系统的架构图中，多个服务器节点的地位是相同。

分布式架构的优点

从当前来看，分布式的架构主要有高并发，高稳定的特点。

高并发是指当单节点服务器的性能已经达到了瓶颈之后，可以通过引入Nginx，部署多个服务器节点的方式来扩容，增加系统的吞吐量。这就是 1*N =N的意义。

高稳定是指如果由于不可预测的原因，发生了单个或部分节点宕机，不会影响系统整体的功能服务，即M-N>0(其中M>N)，对于用户来说，系统可用永远是最重要的。

以上两点对评估系统性能，以及服务口碑方面有着非常重要的意义。

综上，根据我个人的经验，目前不论是市场级产品还是公司级产品，只要是对服务质量有追求的项目组，都会殊途同归发展到分布式架构。

此外，对于功能不是非常复杂庞大的项目组来说，只要在最开始开发设计阶段，就及时引入memcache或者Redis作为数据缓存，而不是使用server的内存，那么后期切换为分布式系统的过程也会十分快捷。

以上是我的个人浅见，欢迎各位在下方评论区与我沟通。

我是苏苏思量，来自BAT的java开发工程师，每天分享科技类见闻，欢迎关注我，与我共同进步。

灰度发布如何实现，其中的原理能帮忙说说吗？

灰度发布，是在软件开发过程中的一种交付方式，而提到交付方式，就不得不说F5，F5可是在应用交付解决方案领导者。

F5除了传统的A/B测试场景之外，还可以在线复制生产系统的流量到测试系统。

其原理就是，用户数据的升级并不是大面积的一次性升级，而是通过一个用户升级标志服务器，如果用户数据没有升级，后台会把此用户的数据逐步迁移到新版本上，然后将升级标志位置1，升级过程中，用户仍然可以访问旧的数据，升级完成后的访问都将转发给新的版本。

蓝绿部署和灰度发布区别？

1、蓝绿发布（Blue/Green Deployment）

蓝绿部署：是不停老版本，部署新版本然后进行测试。

确认 OK 后将流量切到新版本，然后老版本同时也升级到新版本。

特点：蓝绿部署无需停机，并且风险较小。

2、灰度发布

灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。

AB Test 就是一种灰度发布方式，让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

题主做软件的应该听说过“没有银弹”这句话吧？如果真有一个能解决所有问题的软件，还要这么多软件开发人员干嘛？如果有人说有，不是没干过软件，就是在打广告。

“微服务”不是银弹，解决不了所有问题，有其自己的适应场景。我大致总结了如下场景：

• 业务发展较快，希望能在后期快速的支撑爆发增长的访问量（首先确认是不是真的业务发展很快）
• 业务非常复杂，且有很多不确定性，可以考虑领域驱动设计 微服务实现
• 项目很大，人员很多，考虑切分为多个小组进行微服务开发
• 需要整合很多的老系统，可以考虑微服务的sidecar模式或者SOA
• 希望在公司层面构建一套统一的业务技术平台。登陆，文件服务，日终服务等，由业务平台提供，开发人员只需要关注业务服务

相对的，需要快速落地的简单业务就不适合微服务，后期维护成本远超成本。

就像，大型超市有多个收银台，小超市也搞多个收银台，营业额还不够发人员工资的。

最后，技术是为业务服务的，一个技术在某个场景的优势，在另一个场景下可能就变成了劣势，抛开业务讨论哪个技术好不好，都是耍流氓～

k8s灰度发布方案 什么叫系统灰度推送 数据库灰度发布方案

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。