3：回顾微服务和微服务架构

什么是微服务

“微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。”
究竟什么是微服务？引用ThoughtWorks公司 马丁弗勒
原文：https://martinfowler.com/articles/microservices.html
汉化：https://www.cnblogs.com/liuning8023/p/4493156.html
就目前而言，对于微服务，业界并没有一个统一的，标准的定义
但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分成一组小
的服务，每个服务运行在其独立的白己的进程内，服务之间互相协调，互相配置，为用户提供最终价值。服务
之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体的业务进行构建，并旦能够被独立的部署到生产
环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选
择合适的语言，工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语
吉来编写服务，也可以使用不同的数据存储；

微服务架构的一些通用特性

根据MartinFowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：

1. 通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
2. 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。
3. 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
4. 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
5. “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
6. “去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
7. 基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
8. 故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
9. 演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。

微服务架构的优点

1. 每个服务都比较简单，只关注于一个业务功能。
2. 微服务架构方式是松耦合的，可以提供更高的灵活性。
3. 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
4. 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
5. 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
6. 每一个微服务都有自己的存储能力，都可以有自己的数据库，也可以是统一的数据库。

微服务架构的缺点

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

1. 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
2. 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
3. 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
4. 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
5. 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
6. 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。

7. 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

   微服务架构的取舍

8. 在合适的项目，合适的团队，采用微服务架构收益会大于成本。

9. 微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
10. 需要避免为了“微服务”而“微服务”。
11. 微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

    微服务技术栈有哪些

    分布式技术栈

为什么使用SpringCloud

springCloud不是指单独的一个框架，而是我上面说到的一系列，他都给我们做了支持。就像他的名字一样，cloud：他为微服务提供了一个运行的生态环境。
1、他使用springBoot的actuator做健康监控，而且支持使用者通过继承AbstractHealthcator抽象类，重写doHealthCheck方法来定制化健康监控端点，同时提供http接口对外暴露系统健康状况。
当然，他不止监控了健康状况，还监控了jvm运行情况等，使用项目根路径加/actuator可以查看他监控的具体内容的查看路径
2、Spring Boot Admin 则提供了可视化actuator监控到的内容，主要功能点：
显示应用程序的监控状态
应用程序上下线监控
查看 JVM 和线程信息
可视化的查看日志及下载日志文件
动态切换日志级别
HTTP 请求信息跟踪等实用功能
将 actuator 提供的数据进行可视化
3、springCloud使用eureka来做注册中心，就是dubbo服务中的zk角色。
eureka分为服务端即：注册中心，和客户端，就是dubbo框架中的服务提供者和服务消费者
eureka客户端框架和dubbo框架不同的是，eureka支持的消费者和提供者之间的请求是restFul和http，而且两者是完全解耦的，不需要同时引用接口jar包
eureka支持actuator监控，用户可以通过定制健康端点，添加健康检查配置来通知注册中心自身服务的健康状态是up还是down
eureka服务端也支持集群部署，多个eureka服务只需要一套程序的不同application.properties文件就可以，只要相互之间配置上集群其他服务的地址，他们之间就可以进行注册内容复制。客户端访问任意一台服务，获得的服务提供者信息都是相同的。
eureka的服务信息是使用currentHashMap存储在内存的，所以不需要额外的数据库服务。
4、springCloud中可以使用ribbon做客户端负载均衡，通过配置eureka注册中心信息，支持从eureka获取服务提供方的信息列表
ribbon也可以单独使用
5、eureka客户端提供的是restful和http交互，springCloud提供了openFeign框架，是对feign做的封装，使其支持springCloud环境友好使用。
6、服务容错
7、springCloud使用zuul做网关
8、springCloud使用Sleuth关联整个请求链路，做链路跟踪
9、springCloud使用apollo做配置中心。apollo是携程提供的，应该是自己内部用，开源出来的，应为有实战经验，所以用很多实用的功能。
10、安全认证
11、灰度发布

各微服务框架对比