目录
一.传统架构优略分析
1). 单体应用架构
优点：项目前期开发节奏块，团体成员少可以快速迭代；
架构简单，VC架构，只需借助IDE开发、调试即可；
易于测试，只需借助单元测试或者浏览器即可；
易于部署，打成单一可执行的jar或者打成war包放到容器内启动；
缺点：随着不断的功能迭代，单个项目过大，代码杂乱，耦合严重，维护成本高；
新增业务困难，新人难接手任务，学习成本高；
核心业务与边缘业务混合，出现问题相互影响；
2). 垂直应用架构
优点：拆分系统实现流量分担，可以解决并发问题；
可针对不同模块进行优化；
水平拓展方便，负载均衡，容错率提高；
系统之间相互独立，互不影响， 新业务迭代时更加高效；
缺点：服务间相互调用，如果某个服务的端口或ip地址发生改变，调用方需要手动改变；
搭建集群之后，实现负载均衡比较复杂，如：内网负载， 在迁移机器时会影响调用方的路由，导致线上故障；
服务间调用方式不统一，基于httpclient、webService，接口协议不统一；
服务监控不到位：除了依靠端口、进程的监控、调用的成功率、失败率、总耗时等监控指标没有；
3). SOA应用架构
优点：分布式、松耦合、扩展灵活、可重用；
可以解决接口协议不统一、服务无法监控、服务的负载均衡等问题；
服务提供端端口号，ip地址修改，调用方无需手动修改（即实现服务注册与发现）；
缺点：服务抽取粒度较大，服务调用方与提供方耦合度高（接口耦合）；
4). 微服务应用架构
微服务架构可以说是SOA架构的一种拓展，该架构模式下， 模块拆分粒度更小，服务也更独立。不同服务可以使用不同的开发语言和存储，服务间可通过Restful等轻量级通信。强调的是业务彻底的组件化和服务化；
二.微服务架构的思想与优缺点
微服务架构的核心思想就是"微"， 拆分粒度相对较小，这样单一职责，开发的耦合度降低，微小的功能可以独立的拓展，灵活性强，升级改造影响的范围小。
微服务架构优点：便于特定业务功能的聚焦；
每个微服务可以单独实施（开发、测试、部署上线、运维），团队合作一定程度解耦，便于实施敏捷开发；
便于重用和模块之间的组装；
微服务很独立，不同微服务可以使用不同语言开发，松耦合；
容易引用新技术，可以更好的实现DevOps开发运维一体化；
微服务架构缺点：分布式复杂难以管理，当服务数量增加，管理越加复杂；
出现问题后，分布式链路跟踪难；
三.微服务架构的概念
1).服务注册与发现
服务注册：服务提供者将所提供服务的信息注册到注册中心；
服务发现：服务消费者从注册中心获取到较为实时的服务列表，然后根据一定的策略选择一个服务访问；
2).负载均衡
即将请求压力分配到多个服务器（应用服务器、数据库服务器），以此来提高服务的性能、可靠性；
3).熔断
即断路保护。在微服务架构中如果下游服务因访问压力过大而响应变慢或失败、上游服务为保护系统整体可用性，可暂时切断对下游服务的调用，牺牲局部，保全整体；
4).链路追踪
在微服务架构中，一个项目往往拆分成多个服务。不同服务可能有不同团队开发，可能使用不同的编程语言实现，整个项目也可能部署在多个服务器上，而链路追踪，就是对一次请求涉及的多个服务链路进行日志记录，性能监控；
5).API网关
不同的微服务往往有不同的访问地址，客户端可能需要调用多个服务接口才能完成一个业务需求，如果让客户端直接与各服务通信可能会出现：
1：客户端需要调用不同的url地址，增加维护难度；
2：在一定场景下，存在跨域请求问题；
3：每个服务需要进行单独的身份验证；
API网关可以较好的统一处理上述问题，API请求调用统一接口接入API网关曾，由网关转发请求。API网关更加专注在安全、路由、流量等问题处理上，微服务可以更加专注于处理业务逻辑，功能如：
1：统一接入 (路由)；
2：安全防护 (统一鉴权)；
3：黑白名单；
4：协议适配；
5：流量管控；
6：长短连接支持；
7：容错能力 (负载均衡)；
603
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
