一、分享MarkDown小技巧

  1. 最初只需要记住 #标题一、## 标题二、1. 第一点、* 这一点，用这几个写写日志、需求文档、小文章，排版上足够了；
  2. 逐渐你会发现有些文字需要重点指出，那么还可以使用** 加粗 ** 、* 斜体 *来对文字做重点说明；
  3. 如果你是一名程序员，那么可以使用```把代码块包起来，渲染后可以关键字高亮，用>可以做引用；

二、什么是微服务架构

2.1 微服务架构概述

  • 简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成很多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP RESTful API 进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

2.2 与单体系统的区别

  • 在以往传统的企业系统架构中，我们针对一个复杂的业务需求通常使用对象或业务类型来构建一个单体系统。由于单体系统部署在一个进程内，往往我们修改了一个很小的功能，为了部署上线会影响其它功能的运行。并且，单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，对于资源的利用又相互影响，这样使得我们各个业务模块的系统容量很难给出较为准确的评估。所以，单体系统在初期虽然可以较为方便的开发和使用，但是随着系统的发展，维护成本会变得越来越大，且难以控制。
  • 为了解决单体系统变得庞大臃肿之后产生的难以维护的问题，微服务框架诞生了并且被大家广泛关注。我们将系统中的不同功能模块拆分成多个不同的服务，这些服务都能够独立部署和扩展。由于每个服务都在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其他服务的运行。同时，由于是独立部署，我们可以更加准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以很容易地发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。

2.3 如何实施微服务

  • 在实施微服务之前，我们必须要知道，虽然微服务有很多优点,但是也因为服务的拆分引发了诸多（缺点）原本在单体应用中没有的问题：
    + 运维的新挑战:在微服务架构中，运维人员需要维护的进程数量大大增加。有条不紊地将这些进程编排和组织起来不是一件容易的事情，传统的运维人员很难适应这样的改变。我们需要运维人员有更多的技能来应对这样的挑战，运维过程需要更多的自动化，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。
    + 接口的一致性：虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖并为了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正常调用。我们需要更完善的接口和版本管理，或是严格的遵循开闭原则。
    + 分布式的复杂性:由于拆分后的各个微服务都是独立部署运行在各自的进程内，它们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等。
  • 尽管微服务有很多的缺点，但是其实现的敏捷开发和自动化部署等优点依然被广大优秀的架构师和开发者所青睐，微服务架构的九大特性：
    1.服务组件化
    2.按业务组织团队
    3.做“产品”的态度
    4.智能端点与哑管道
    5.去中心化治理
    6.去中心化管理数据
    7.基础设施自动化
    8.容错设计
    9.演进式设计
  • 服务组件化:组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。在微服务的架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样以嵌入式的方式协同工作。每一个服务都独立开发、部署，可以有效避免一个服务的修改引起整个系统的重新部署。
  • 按业务组织团队:在实施微服务架构时，需要采用不同的团队分隔方法。由于每一个微服务都是针对特定业务的宽栈或者全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种专业领域的职能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按照业务线的方式进行拆分，一方面可以减少服务内部修改所产生的能耗；另一方面，团队边界可以变得更为清晰。