- 微服务是什么
- 概念
- 定义
- 本质
- 传统开发模式和微服务的区别
- 先来看看传统的web开发方式
- 微服务
- 意识的转变（传统开发转向微服务）
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持
概念把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
传统开发模式和微服务的区别 先来看看传统的web开发方式 传统web开发(单体式开发)
优点：
①开发简单，集中式管理
②基本不会重复开发
③功能都在本地，没有分布式的管理和调用消耗
缺点：
效率低：开发都在同一个项目改代码，相互等待，冲突不断
维护难：代码功功能耦合在一起，新人不知道何从下手
不灵活：构建时间长，任何小修改都要重构整个项目，耗时
稳定性差：一个微小的问题，都可能导致整个应用挂掉
扩展性不够：无法满足高并发下的业务需求
- 常见的系统架构遵循的三个标准和业务驱动力： 提高敏捷性：及时响应业务需求，促进企业发展
提升用户体验：提升用户体验，减少用户流失
降低成本：降低增加产品、客户或业务方案的成本 - 基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署
微服务的优点
关键点：复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高
①它解决了复杂性的问题。它会将—种怪异的整体应用程序分解成-组服务。虽然功能总量不变，
但应用程序巴分解为可管理的块或服务。每个服务都以RPC或消息驱动的AP的
形式定义了一个明确的边界； Microservice架构模式实现了一个模块化水平。
②这种架构使每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的
技术，只要该服务符合AP合同。当然，大多数组织都希望避免完全无政府状态并
限制技术选择。然而，这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的
技术。在编写新服务时，他们可以选择使用当前的技术。此外，由于服务相对较小
因此使用当前技术重写旧服务变得可行。
③ Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。
这些变化可以在测试后尽快部署。例如，U团队可以执行A|B测试，并快速迭代
U更改。 Microservices架构模式使连续部署成为可能。
④ Microservice架构模式使每个服务都可以独立调整。您可以仅部署满足其容量和可用性限制的每」
个服务的实例数。此外，您可以使用最符合服务资源要求的硬件。
微服务的缺点
①一个缺点是名称本身。术语microservice过度强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署
②微服务器的另一个主要缺点是分布式系统而产生的复杂性。开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，
因为请求的目的地可能很慢或不可用。
③微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务交易是相当普遍的。但是，在基于微服务器的应用程序中，您需要更新不同服务所拥有的多个数据库。使用分布式事务通常不是一个选择，而不仅仅是因为CAP定理。许多今天高度可扩展的NoSQL数据库都不支持它们。你最终不得不使用最终的一致性方法，这对开发人员来说更具挑战性。
④测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样做的复杂性。
⑤Microservice架构模式的另一个主要挑战是实现跨越多个服务的更改。例如，我们假设您正在实施一个需要更改服务A，B和C的故事，其中A取决于B和B取决于C.在单片应用程序中，您可以简单地更改相应的模块，整合更改，并一次性部署。相比之下，在Microservice架构模式中，您需要仔细规划和协调对每个服务的更改。例如，您需要更新服务C，然后更新服务B，然后再维修A.幸运的是，大多数更改通常仅影响一个服务，而需要协调的多服务变更相对较少。
⑥部署基于微服务的应用程序也更复杂。单一应用程序简单地部署在传统负载平衡器后面的一组相同的服务器上。每个应用程序实例都配置有基础架构服务（如数据库和消息代理）的位置（主机和端口）。相比之下，微服务应用通常由大量服务组成。例如，每个服务将有多个运行时实例。更多的移动部件需要进行配置，部署，扩展和监控。此外，您还需要实现服务发现机制，使服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统的基于故障单和手动操作的方法无法扩展到这种复杂程度。因此，成功部署微服务应用程序需要开发人员更好地控制部署方法，并实现高水平的自动化。
微服务对我们的思考，更多的是思维上的转变。对于微服务架构：技术上不是问题，意识比工具重要。
关于微服务的几点设计出发点：
1、应用程序的核心是业务逻辑，按照业务或客户需求组织资源（这是最难的）
2、做有生命的产品，而不是项目
3、头狼战队，全栈化
4、后台服务贯彻 Single Responsibility Principle（单一职责原则）
5、VM-> Docker（toPE）
6、 DevOps（toPE)
同时，对于开发同学，有这么多的中间件和强大的PE支持固然是好事，我们也需要深入去了解这些中间件背后的原理，知其然知其所以然，在有限的技术资源如何通过开源技术实施微服务？最后，一般提到微服务都离不开 DevOps和 Docker，理解微服务架构是核心，dev.ps和 docker是
工具，是手段。
参考文张
什么是微服务架构？
