微服务概念

微服务概念

良马难乘，然可以任重致远；良才难令，然可以致君见尊。

微服务已经成为软件领域的新宠。
微服务已经到来，只是还没有平均分布。
微服务的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的例子。

微服务架构的出现是符合事物发展规律的：当问题足够大、有足够多的不确定性因素时，人们习惯把大的问题拆分成小的问题，
通过分割、的抽象和重用小而可靠的功能模块来构建整体的方案。

架构就是取舍，架构师就是做出取舍的人。多数时候，困扰人们的不是“什么才是正确的”，而是“取舍之间”。开发者和架构师
应该具备选择和取舍的能力，应该站在比较高的角度俯瞰全局、权衡利弊，做出正确的架构和技术选择。

为架构师提供一个微服务的全局视野。

将初始化、配置、监控和管理等各种复杂的功能捆绑到一个单体架构中，这给开发和运维都带来了挑战。

用一系列松散耦合的服务取代了单体。

微服务这个词在2011年的软件架构研讨会上被用来描述这种架构。

小型、松散耦合的团队快速可靠地开发和运维微服务的思想正在通过软件社区慢慢扩散。

单体地狱（此处省略若干文字）

软件架构其实对功能性需求影响并不大。架构的重要性在于它影响了应用的非功能性需求，也称为质量属性或者其他的能力。

服务本质上是一个麻雀虽小但五脏俱全的应用程序，它实现了一组相关的功能，例如订单管理、客户管理等。
例如，订单服务可以被部署为一组负载均衡的服务实例。
把应用程序功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。

模块化是开发大型、复杂应用程序的基础。
为了让不同的人开发和理解，大型应用需要拆分模块。在单体应用中，模块通常由编程语言所提供的包来定义。

微服务架构使用服务作为模块化的单元。服务的API为它自身构筑了一个不可逾越的边界，你无法超过API去访问服务内部的类。
因此模块化的服务更容易随着时间推移而不断演化。

微服务架构的一个关键特性是每一个服务之间都是松耦合的，它们仅通过API进行通信。实现这种松耦合的方式之一，是每个服务都拥有
自己的私有数据库。订单服务拥有一个包括订单表的数据库，客户服务拥有一个包含客户表的数据库。在开发阶段，开发者可以修改自己
服务的数据库模式，而不必同其他服务的开发者协调。在运行时，服务实现了相互之间的独立。服务不会因为其他的服务锁住了数据库而
进入堵塞的状态。

每一个服务拥有它自己数据库的需求并不意味着每个服务都需要一个独立的数据库服务器。

API网关把来自前端的请求路由到服务实例。API网关扮演了一个对外的角色。
应用程序的业务逻辑由众多后端服务组成。每个后端服务都有一个REST API和它自己的私有数据库。
每个服务及其API都有非常清晰的定义。每个都可以独立开发、测试、部署和扩展。开发人员无法绕过服务的API访问其内部组件。

SOA应用常常选用重量级的技术，例如SOAP。SOA常常使用ESB进行服务集成，ESB是包含了业务和消息处理逻辑的智能管道。
采用微服务架构设计的应用程序倾向于使用轻量级、开源的技术。服务之间往往使用哑管理（例如消息代理）进行通信，使用REST或gRPC
这类轻量级协议。
SOA应用一般都有一个全局的数据模型，并且共享数据库。与之相反微服务架构中每个服务都有属于它自己的数据库。
SOA善于集成大型、复杂的单体应用程序。
微服务架构中的服务虽然不是必须要做到很小，但是通常都比较小。
SOA应用通常包含和集成若干个大型的服务，微服务架构的应用则常常由数十甚至上百个更小的服务组成。

你可以将工程组织构建为一个小型团队的集合。每个团队全权负责一个或多个相关服务的开发和部署。每个团队可以独立于所有其他团队
开发、部署和扩展他们的服务。结果，开发的速度变得更快。

因为每一个服务都相对较小，编写和执行自动化测试变得很容易。因此，应用程序的BUG也就更少。

每个服务都可以独立于其他服务进行部署。如果负责服务的开发人员需要部署对该服务的更改，他们不需要与其他开发员协调就可以进行。
因此，将更改频繁部署到生产中更容易得多。

每个服务都相对较小并容易维护。

因为每个服务都比较小，开发者更容易理解服务中的代码。较小规模的代码库不会把IDE拖慢。

服务的启动速度比大型的单体应用快得多，快速启动的服务会提高效率，加速研发。

某个服务中的内存泄漏不会影响其他服务。其他服务仍旧可以正常地响应请求。相比之下，单体架构中的一个故障组件往往会拖垮整个系统

微服务架构可以消除对某项技术栈的长期依赖。原则上，当开发一个新的服务时，开发者可以自由选择适用于这个服务的任何语言和框架。
因为服务都相对比较小，使用更好的编程语言和技术来重写一项服务变得有可能。如果对一项新技术的尝试以失败而告终，我们可以直接
丢弃这部分工作而不至于给整个应用带来失败的风险。

服务的拆分和定义更像是一门艺术。如果对系统的服务拆分出现了偏差，你很有可能会构建出一个分布式的单体应用：一个包含了一大堆
互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。这将会把单体架构和微服务架构两者的弊端集于一身。

服务必须使用进程间通信机制。这比简单的方法调用更复杂。

每个服务都有自己的数据库，这使得实现跨服务的事务和查询成为一项挑战。

IDE开发工具都是为单体应用设计的，它们并不具备开发分布式应用所需要的特定功能支持。

软件工程的世界里没有银弹。换一种说法，并不存在一种或几种技术，可以把你的生产效率提升10倍。每一项技术都有它的弊端和限制。
这些总是被它们的鼓吹者所忽视。

使用微服务架构构建的应用程序是分布式系统。因此，进程间通信（IPC）是微服务架构的重要组成部分。

微服务架构的关键挑战是将应用程序功能分解为服务。因此，架构设计的第一个也是最重要的工作就是服务的定义。