|
对于业务系统，基于业务量、数据量、稳定性要求等，选择合适的架构是产品开发的第一步。 01 4、系统故障影响大，需要人工马上介入，缺少故障转移机制 在业务成长的过程中，多方面系统瓶颈问题，不一一列了，需要结合架构来做优化升级。 作为一个软件开发人员，需要了解软件构建的演进，熟悉常用的软件架构。02 软件行业最初流行的是单体架构，整个项目包含的模块非常多。 典型的有三级架构，前端(Web/客户端) + 业务服务层 + 数据库层。常见的开发框架比如有Java Spring MVC。 单体架构的应用比较容易部署、测试，在项目的初期，可以很好地运行。随着需求的不断增加， 越来越多的人加入开发，代码库也同时在膨胀。 产品功能做大后，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。03 分布式应用是中级架构，中间层和数据层都为分布式，是并发扩展单体架构。 经历过单体应用开发的人员，自然会想到拆分多个业务系统，每个系统部署在不同的服务器上，各个服务模块之间通过接口做数据交互。 数据层也大量采用分布式数据库，比如Redis、ES、MongoDB。通过Nginx等代理应用，将用户请求均衡分发到不同的服务器。 相对于单体架构来说，还是水平扩展系统，提供了负载均衡的能力，可以大大提高系统负载能力，解决高并发的需求。 缺点是系统之间的交互要使用远程通讯，接口的开发量变大，不过嘛，这点问题不大。
04 微服务架构，主要是分解中间层，将系统拆分成很多微服务，微服务可以部署在不同的系统，也可以部署在相同服务器上的不同容器。 单个应用的负载和故障不直接影响其他应用，常见的框架有 Spring Cloud、Dubbo等。典型的微服务部署架构可参考下图。
微服务带来很多优点 1、易于开发和维护：每个服务关注一个指定的业务板块，业务清晰，微服务之间设计的解耦。
2、按单个服务部署：每个服务代码量较少，一般只改了某个服务，就只要重新部署这个服务，启动比较快。
3、服务治理更专业：可以做更细粒度的服务治理，更精确的流量管控等。 4、技术栈不受限：每个服务可选不同的技术栈和中间件，甚至支持不同的开发语言。
微服务带来一些挑战 微服务可便于项目做大做强，同时日常要面临以下挑战 1、分布式的复杂性：系统各方面设计需要考虑分布式，处理网络延迟、系统容错、分布式事务等带来的挑战。
2、接口调整成本高：微服务之间通过接口通讯，一个接口修改可能所有调用该接口的服务都需要同步调整。
3、运维要求较高：微服务的部署数量常见的几十到几百，要保证相互正常运行和协作，以及容器的自动伸缩，运维技能要求很可能上升到使用 K8s。
05 各个业务中间件做高可用部署，比如MySQL数据库主从、Redis集群部署等，同时代码层面要做的处理。 基于用户的请求，从业务上游、中游到下游，Nginx负载均衡、微服务网关、服务负载均衡等。
并发流量大情况下，如何保证系统稳定的一些考量，比如消息队列、服务降级、限流、超时机制等。 今天开始新增加一个分享主题，关于架构高可用的技术选型、搭建、使用等。 主要基于微服务架构，有需要分享的同学点个赞，让我知道你需要。
|
