传统软件架构与微服务架构

一、软件架构是什么

        软件架构是在软件的内部，经过综合各种因素的考量、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此写作，为用户提供需要的价值。

二、考虑的因素有哪些？

        1、业务需求

        2、成本

        3、技术栈

        4、组织架构

        5、可扩展性

        6、可维护性

三、单体架构

        定义：功能、业务集中在一个发布包里，部署运行在同一个进程中。

四、单体架构的优势

        1、易于开发，很容易理解

        2、易于测试

        3、易于部署

        4、易于水平伸缩

五、单体架构面临的挑战

        1、代码膨胀，难以维护

        2、构建、部署成本大

        3、新人上手困难

        4、创新困难

        5、可扩展性差

六、什么是微服务

       使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且他们可以通过采用自动化的方式部署。

      微服务特征

        1、单一职责，只把相关的机制放在一起，跟这个业务不在紧密的可以分出去

        2、轻量级通信，与平台无关、语言无关的通信机制，如protobuf

        3、隔离性

        4、有自己独立的数据存储系统

        5、微服务可以由开发人员选择最适合自己的语言（技术多样性）只需要提供相应的api

        微服务诞生背景

        1、互联网行业的快速发展

        2、敏捷开发、精益开发

        3、容器技术的成熟，docker有效解决了微服务数量的庞大。

        微服务的架构图（熟悉微服务）

假定业务场景：

1、一个在线教育网站的部分功能

2、用户可以登录注册、获取用户信息

3、由发送邮件发送短信功能

3、可以查看课程列表

 微服务架构优势

        1、每个服务都是相互独立的，可以根据qps的多少，来启动多少个微服务，扩缩容相对容易、都有自己独立的数据库。

        2、技术栈灵活。每个微服务只需要保证自己的api接口

        3、高效团队，团队需要的非常少。

微服务架构不足

        1、需要对原有的系统进行微服务划分

        2、数据一致性、微服务的数据库不同。

        3、沟通成本，如果api改变，如果想修改就需要别的团队联合修改

微服务间如何通讯

	一对一	一对多
同步	请求响应模式，最常见	-------
异步	通知/请求异步响应	发布订阅/发布异步响应

从通讯协议角度考虑        

1、REST api    在网络中客户端和服务端进行通讯的一种格式

2、RPC   dubbo\dubbox\motan\grpc\thrift

3、MQ     消息队列

RPC 微服务之间通信大部分都是这种

        如何选择RPC框架？

        1、I/O、线程调度模型（看是否单线程、多线程）

        2、序列化方式（json\xml 可见）（protobuf 不可见）

        3、多语言支持  （看业务是否跨度高）

        4、服务治理（看是否有服务的监控等，一般有服务治理的框架，可以方便集群部署）