社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
一、单体架构
把功能、业务集中在一个发布包里，部署运行在同一个进程中的应用就是单体架构。
优势：
1、易于开发
2、易于测试
3、易于部署
4、易于水平伸缩
单体架构面临的挑战：
1、代码膨胀，难以维护
2、构建，部署成本大，持续交付周期长
3、新人上手困难
4、创新困难
5、可扩展性差
二、微服务架构
使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化的方式部署。
微服务的特征：
1、单一职责
2、轻量级通信
3、隔离性
4、有自己的数据库，把业务数据独立
5、技术多样性
微服务诞生背景实在互联网行业的快速发展，敏捷开发，精益方法深入人心，容器技术的出现也为微服务架构的出现奠定了技术基础。
微服务的优势：
1、独立性，每个服务是独立的，在扩容上可以做的很精细，减少资源浪费。服务出问题时也不影响其他服务，提高整个系统的可用性。
2、敏捷性，微服务可以快速的应对变化，当有新需求时只需要修改与需求相关的服务，不影响其他服务。
3、技术栈灵活，每个微服务可以有自己独立的技术栈，只需要保证接口不变，这样的架构非常适合尝试新技术，非常容易升级技术栈。
4、高效团队，每个团队只需要维护自己负责的微服务，当需求更改时，小团队内部开会进行迭代即可。
微服务的缺点：
1、额外的工作，微服务增加了服务拆分的工作，如何拆分微服务是一门很深的学问。
2、数据一致性，单体架构只有一个数据库，使用事务就可以保证数据一致性。但是微服务各有各的数据库，如何保证数据一致性是一个难点。
3、沟通成本，单体架构修改某个接口时，可以一并把调用接口的地方更改，但是微服务时修改接口时，需要整个大团队一起沟通，增加了沟通成本。
微服务架构引入的问题及解决方案：
1、微服务间如何通讯？
在单体架构中，接口大部分都是在应用内部调用。微服务的接口通常都是给其他微服务调用的，我们先从通信方式去考虑。
那么从通信协议角度去考虑：
1)、rest api 是基于http协议来实现rest风格的api
2)、rpc协议，业内常见的rpc框架有dubbo，grpc，motan，thrift等等
业界微服务通信最常用的通信方式是rpc通信，那么每个rpc框架各有什么特点呢？
1)、dubbo
dubbo是阿里开源的一款rpc框架，提供者通过注册中心注册服务，消费者通过注册中心订阅服务。消费者和提供者和注册中心都使用的是长连接，消费者和提供者之间使用的通信是非阻塞io，dubbo的序列化使用的阿里修改过的fastjson序列化。dubbo是java开发，支持单语言，不支持多语言，dubbo集成好了服务发现和服务治理，所以dubbo有完善的服务发现和服务治理的解决方案。
2)、Motan
Motan是新浪微博2016年开源的rpc框架，支撑了微博每天千亿级别的调用量。Motan用起来非常简单，通过spring配置接入。server通过注册中心发布，client通过注册中心订阅服务，原理和dubbo类似。当server发生变更时，registery也会同步到client。Motan也只支持java语言，并不支持多语言。
3)、Thrift
Thrift是2007年Facebook开源的跨语言的rpc框架。使用thrift的时候需要定义一个thrift文件，通过thrift生成对应语言server和client的代码，生成之后服务的提供者和消费者都需要引入代码，提供者实现API，消费者通过API调用服务。server和client的代码可以是不同语言的，从而实现了多语言的支持。在传输的序列化上支持二进制模式，压缩模式，json模式等等。在开发环境可以用json模式方便debug和调试，在生产环境可以使用二进制模式提升性能。在通信模式上支持阻塞io也支持nio。Thrift没有提供服务发现和服务治理的功能，需要开发者自己实现。
4)、Grpc
Grpc是Google开源的rpc框架，这个框架原理和thrift类似，也需要定义个proto文件，通过protoc生成各个语言的接口，实现跨语言的通信。grpc的数据传输都是用的protobuf，这是一个非常高效的序列化方式。另外由于grpc主要用在移动端，所以底层并没有采用socket协议，而是选择了http2.0协议进行数据传输。
目前主流rpc框架性能对比如下图所示。序列化效率方面是grpc的protobuf效率最高，但是由于grpc没有采用传统的socket通信协议，而是选择了http2.0，所以在传输性能上要次于thirft。不过从实际应用来说，4个框架都能满足大部分的生产需求。
2、微服务如何发现彼此？
服务发现的本质是让调用者如何能知道服务提供者的ip和端口号，服务发现分为客户端发现和服务端发现。
客户端服务发现是当微服务启动之后都会把自己的ip和端口号告诉注册中心，客户端通过查询注册中心注册的服务得知提供者的ip和端口列表，通过负载均衡策略来实现对微服务的无差别访问。
服务端服务发现是客户端不需要去访问注册中心，而是通过一个固定的ip或者是域名来访问具有负载均衡和服务发现的一个服务，再由这个服务将请求转发给后端的各个服务，并且将应答回传。这个服务会访问注册中心把已经注册的服务维护在自己内部，当客户端请求一个服务时，它会通过负载均衡算法去选择一个正确的服务发起请求。
3、微服务怎样部署？更新？扩容？
传统单体架构部署和更新代码时，是需要对各个服务器节点都安装配置好环境，然后一个一个下线更新上线，当业务体量比较小的时候，这样的架构还不会产生什么问题，但是一旦业务体量变大，需要维护的服务器数量增至数十台时，这对于运维的工作量来说是非常巨大的，每一次版本迭代都会让运维提心吊胆，生怕漏了或者部署错误。
但是对于微服务的部署，数十个服务的部署更新对运维是一个更大的挑战，所以业界也出现了服务编排技术，目前流行的服务编排工具有Mesos、Docker Swarm和Kubernetes。在市场的选择下，Kubernates逐渐占据上风，成为服务编排解决方案的事实标准。运用Docker容器化技术+Kubernates服务编排，可以极方便的编写自动化部署脚本，实现服务快速部署更新和扩容，为微服务的持续集成和交付带来了解决方案。
三、设计一个小型微服务应用
学习微服务，那么肯定是需要想一个业务场景，现在在线教育比较火，那就做一个在线教育的网站吧。
1、用户可以登录，注册，获取用户信息
2、发送邮件功能
3、查看课程列表和对课程的基本crud
四、创建工程
开始画架构图，这次学习选择了两款rpc框架，分别是单语言的dubbo和跨语言的thrift。
架构图画完了，那么就开始初始化工作吧，我是用idea创建maven的工程模板。
接下来初始化git，推送到远程仓库。
自此，整个工程的初始化工作就已经完成了。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
