分布式+微服务架构
随着互联网技术的飞速发展，目前全球超过半数以上的人口在使用互联网，人们的生活、工作随着互联网的发展，发生了翻天覆地的变化。

我们的工作随着越来越多的用户参与，业务场景越来越复杂，云计算、大数据、区块链、人工智能的飞速发展对系统架构也提出了越来越高的要求，我们原来使用的单体架构已经不能满足工作场景需求。

此时Martin Fowler提出来了微服务架构，一个分布式系统架构，按业务领域划分为独立的服务单元，满足越来越复杂的业务需求，并且可以自动化运维、容错、快速演进。

微服务是“互联网+时代”催生的一种设计思想和理念。

一、技术架构的前生今世
1、单体架构
单体架构将系统中的所有功能、模块耦合在一个应用中的架构方式。

如MVC架构，表示层（View） + 中间业务逻辑层（Controller） + 数据库层（Model）。

代表技术Spring mvc、Struts2等。

该架构具有以下特点：
1.1、复杂性高、项目包含的模块非常多、模块的边界模糊、依赖关系不清晰，随着业务复杂度的提高，代码的可维护性、扩展性和可读性在降低。

1.2、可靠性差、某个模块的问题（内存溢出）可能会导致整个系统的崩溃。

1.3、扩展能力受限、该构架只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。

1.4、易运维、项目可以直接打成war包发布。

2、SOA架构（面向服务）
SOA架构属于企业领域，将原来的单体架构按照功能分为不同的子系统，然后再由各个子系统依赖服务中间件来调用所需服务。

服务之间采用webservice、rpc等方式进行通信，SOA大部分概念是基于企业服务总线（ESB）的，即企业服务总线作为服务之间通信的桥梁。

该架构具有以下特点：
2.1、重用性、重复的功能抽取为服务，提高开发效率，提高系统的可重用性。

2.2、针对不同服务的特点制定集群及优化方案。

2.3、服务的颗粒度大。

2.4、SOA强调ESB企业服务总线。

为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。

3、微服务架构
应用程序划分成一组小的服务，每个服务都围绕着具体业务进行构建，每个服务运行独立的自己的进程中，能够被独立地部署到生产、测试环境。

服务之间互相协调、互相配合，服务之间采用轻量级的通信机制互相沟通(通信是基于HTTP的RESTful API)为用户提供最终价值。

与SAO架构相
比，不存在一个企业服务总线调度，而是各个服务之间自主发现和调用其它服务，且可以是跨终端跨平台的调用。

SpringCloud提供了一站式微服务解决方案：
二、开发框架
我司目前采用前后端分离开发框架、前端采用Vue框架，后端采用SpringCloud微服务架构。

三、框架名词解释说明
3.1、前后端分离、前端静态代码部署在Apache Server 服务器与后端服务只进行数据交互，所有的页面展现、切换都在前端完成（jsp运行在web服务器端），响应时间短用户体验更好。

前端采用Vue框架，Vue是一个轻量级、高性能构建用户界面的渐进式框架，具有数据双向绑定（MVVM）、组件化等特点；后端采用SpringCloud微服务架构进行开发，每个微服务单独部署、独立运行对外提供接口。

前后端开发按照接口文档约定各自为战。

3.2、Nginx、反向代理功能，客户不想让外部人员看自己的内部，就需要网关来进行反向路由，即将外部请求转换成内部具体服务调用。

负载均衡功能、采用权重等策略对Gateway集群做负载均衡。

3.3、Eureka、 Eureka Server服务注册功能的服务器，它是服务注册中心。

系统中的其他微服务使用 Eureka 的客户端（Eureka Client）注册、连接到 Eureka Server，并维持心跳连接。

可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。

服务消费方从Eureka Server获取注册服务列表，从而能够消费服务，服务消费方可以设置负载均衡，默认策略为轮询。

3.4、Gateway、我司采用Zuul网关、该网关有路由和过滤两个功能。

路由功能实现外部访问统一入口，负责将外部请求转发到具体的微服务实例。

过滤功能指对请求的处理过程进行干预,实现请求校验（登录验证）等功能。

3.5、AuthService、认证中心。

在Gateway登录验证未通过的请求，必须去认证中心采用用户名、密码方式进行登录认证。

认证通过后AuthService会给客户颁发令牌，再次访问时客户带着令牌访问即可。

3.6、Sentinel、流量监控及服务熔断、降级。

应用流量的QPS（每秒请求数量）或并发线程数等指标达到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰冲垮，保障应用高可用性。

如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。

Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资
源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。

当资源被降级后，在接下来的降级时间窗口之内，对该资源的访问都自动熔断。

熔断后可以采用消息队列方式对业务数据进行补偿。

四、架构特点
4.1、以使用服务的方式来实现组件化。

每个服务独立构建、部署（避免了对整个系统的一个小地方的改动，都要对整个系统重新构建，部署的问题）、独立运行、可以独立数据库、针对服务按需收缩，根据需求实现细粒度的扩展。

（例如系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级CPU或者增加节点）
4.2、单个微服务易于开发和维护（擅长的人干擅长的事），服务内高内聚、服务间低耦合。

4.3、持续交付、统一监控。

4.5、做产品不是做项目，基于“谁构建，谁运行”的理念，与做项目的核心区别在于，做完了项目就交付给运维去运维，然而做产品意味着，开发要在产品的整个生命周期中承担一些运维职责。

可以增进开发、运维、客户之间的交流沟通。

4.6、发开成本高、测试的复杂性（系统集成测试）、运维的复杂性。

4.7、多服务、跨数据库访问的数据一致性。

4.8、服务间通信成本。

4.9、系统设计层面如何服务拆分达到最优效果。

五、DevOps
DevOps是一种软件开发方法，涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。

用于促进开发、运营和质量保障（QA）部门之间的沟通、协作与整合；强调共同对业务目标负责，以实现用户价值作为唯一的评判标准：保证产品功能及时实现、成功部署和稳定使用；我司目前采用的DevOps工具：
GitLab（开发）、SonarQube(质量)、Maven（构建）、Docker（容器）。

六、结束语
微服务设计思路是核心，devops是工具、手段。

适合的才是最好的，根据自己的业务选择合适的开发框架。