系统架构分析

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

1.系统架构演变
随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？

其实生活不止眼前的苟且，还有诗和远方。所以我们今天就回顾历史，看一看系统架构演变的历程；把握现在，学习现在最火的技术架构；展望未来，争取成为一名优秀的Java工程师。

1.1.集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

存在的问题：

代码耦合，开发维护困难

无法针对不同模块进行针对性优化

无法水平扩展

单点容错率低，并发能力差

1.2.垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：

优点：

系统拆分实现了流量分担，解决了并发问题

可以针对不同模块进行优化

方便水平扩展，负载均衡，容错率提高

缺点：

系统间相互独立，会有很多重复开发工作，影响开发效率

1.3.分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。

优点：

将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护

1.4.流动计算架构（SOA）
SOA ：面向服务的架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键

以前出现了什么问题？

服务越来越多，需要管理每个服务的地址

调用关系错综复杂，难以理清依赖关系

服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

服务注册中心，实现服务自动注册和发现，无需人为记录服务地址

服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系

动态监控服务状态监控报告，人为控制服务状态

缺点：

服务间会有依赖关系，一旦某个环节出错会影响较大

服务关系复杂，运维、测试部署困难，不符合DevOps思想

1.5.微服务
前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实却有一些差别：

微服务的特点：

单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。

面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。

自治：自治是说服务间互相独立，互不干扰

团队独立：每个服务都是一个独立的开发团队，人数不能过多。

技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉

前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口

数据库分离：每个服务都使用自己的数据源

部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务结构图：

2.服务调用方式
2.1.RPC和HTTP
无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下2种：

RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表

Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

现在热门的Rest风格，就可以通过http协议来实现。

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么SpringCloud搭建微服务是不二之选。在我们的项目中，我们会选择SpringCloud套件，因此我们会使用Http方式来实现服务间调用。

2.2.Http客户端工具
既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

HttpClient

OKHttp

URLConnection

`

# 小结
讲述了系统架构问题
# 参考资料和推荐阅读
1.链接: [参考资料](https://blog.csdn.net/qq_31707969/article/details/105896507).
2.致谢作者