微服务microservice(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-22 04:43:14 (3年前)
关键词: 微服务；microservice
摘要:

                              
                                     微服务是指提供单个业务功能的服务，遵循SOLID原则的单一职责，从技术角度看就是一种小而独立的处理进程，能够自行单独启动或销毁，拥有自己独立的数据库，由独立团队开发，这个团队大小以吃一两个披萨喂饱为判断依据，从业务角度看，团队大小以业务子域或DDD有界上下文划分，或以产品边界划分。

微服务是指提供单个业务功能的服务，遵循SOLID原则的单一职责，从技术角度看就是一种小而独立的处理进程，能够自行单独启动或销毁，拥有自己独立的数据库，由独立团队开发，这个团队大小以吃一两个披萨喂饱为判断依据，从业务角度看，团队大小以业务子域或DDD有界上下文划分，或以产品边界划分。
　　微服务是对传统单体Monolith的否定升级。 从单体SOA到微服务的思路转变：垂直切片的烟囱式故事已经一去不复返了
<h2 id="h2--java-monolith-"><a name="什么是Java整体/单体Monolith？" class="reference-link"></a>什么是Java整体/单体Monolith？</h2>　　假设您正在为一家银行或金融科技初创公司工作。您为用户提供了开设一个新的银行帐户功能，在Java代码中，这将导致一个看起来像简化的控制器类，如下所示。
<pre><code>@Controller
class BankController{
@PostMapping("/users/register")
public void register(RegistrationForm form) {
 validate(form);
 riskCheck(form);
 openBankAccount(form);
 // etc..
}
</code></pre>} 您将要：
<ol>
<li>1、验证注册表。</li><li>2、对用户的地址进行风险检查，以确定是否要给他一个银行帐户。</li><li>3、开立银行账户</li></ol>
BankController类将与所有其他源代码一起打包到一个bank.jar或bank.war文件中进行部署，包含银行运行所需的所有代码。（，.jar / .war文件最初的大小为1-100MB）。然后，在服务器上，您只需运行.jar文件-这就是部署Java应用程序所需要做的全部工作。 　　从本质上讲，Java单体没有错。好处：
<ol>
<li>1、让许多不同的程序员/团队/顾问共享代码…</li><li>2、在在相同的整体代码库上工作…</li><li>3、几年了…</li></ol>
　　然而，当小bank.jar文件变成了一个几百兆或千兆字节大小时，每个人都开始担心部署。 　　企业架构历经几十年的SOA轰轰烈烈建设以后，发现由于强调服务的共享和重用导致巨大臃肿的服务，这就是单体架构(monolith，又称为巨石、整体架构)的由来，其特点是如同炒面菜与面条混在一起，或如意大利面都搅拌在一起，不分彼此，业务逻辑与技术混合在一起，而技术发展很快，这样的系统非常难以维护，因为掌握一个大服务对于新程序员不是一件简单的事情，从容导致交付延迟，软件开发效率降低，国内最近几年推崇的中台概念其实是单体SOA的翻版，可以说是重走老路， 见：中台是一个营销概念！
　　微服务的设计核心是：解耦高于复用，微服务架构是对高耦合的单体架构进行分解，根据DDD子域或有界上下文进行切分，开发团队因此也分成不同的微服务团队，团队之间不需要频繁的沟通开会，提高开发效率，微服务因为小而美，新程序员理解和维护起来非常方便，不会发生改一动百的惊心动魄的问题，更不会导致年底删库的事件发生。　　
　　从软件架构角度看：一个复杂软件架构是由很多这样小而独立运行（有自己的端口）微服务组成，这些独立处理组件之间通讯是通过与语言无关的API进行，简单协议有同步性质的RMI/RPC和 RESTful Web Services，异步的消息推送和Reactive方式。
　　这些模块化的方式能够使得公司将项目分解分散到多个开发团队，跨不同业务部门，提供非常充分的灵活性，帮助提高项目的生命周期，加快项目开发完成效率。
　　每个微服务组件都有自己分配的存储 内存和CPU资源，这就使得硬件利用更加易于优化和跟踪，特别是在基于云的Pass环境，开发团队可以使用他们喜欢的技术，任何语言都可以，只要确保微服务之间是可交互的，能够最终组合起最后的应用。
　　当管理复杂性会因为采取微服务架构而降低，通常更新其中一个微服务组件不会引起连锁反应，因为微服务之间是松耦合的。
　　目前使用微服务的企业有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。
　　因为有很多应用和服务部署在基于云主机的环境中，微服务架构将会严重依赖容器技术，容器隔离了微服务处理过程，将一个应用切分为一个个小的实例，这些容器中的小实例有自己的端口和虚拟化环境。
　　广泛使用的容器技术是Docker, 一种基于Linux的开源实现，由很多软件公司支持如 Canonical, Red Hat,和Parallels. PaaS服务支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。
　　微服务架构不只是传统服务变微变小。微服务两个显著特点是：微服务本身是无状态的；微服务之间很少可变共享。可以设想一下，如果微服务之间可以共享，那么带来两个问题：微服务团队之间需要合作，因为共享的是一个统一数据库，如果这种共享没有带来沟通成本，没有破坏一个团队就能搞定的宗旨，那么这种共享数据库也是可以考虑，但是这种情况很少，大部分团队因为共享问题破坏了独立性；再者，微服务如果使用Docker分别打包在一个容器中，这些容器可能是跨不同基础设施部署，部署方式很灵活，是一种cloud native应用，而共享数据库属于底层基础设施，显然提高了部署难点。
　　另外，传统服务之间通讯无论是RPC/RMI或是Http/RESTful都是同步的，而微服务之间通信最好是异步的或reactive的，也就是非同步的。根据FLP不可能原理，网络默认是不可靠的，RPC在一旦发生网络堵塞会连环爆炸，事后监控并不能根本解决这个问题，需要从CAP定理角度进行平衡设计，引入事件驱动或Pub/Sub消息方式能在提高网络容错性的同时，保证数据最终一致性，柔性事务是微服务环境的主要选择。 　　传统服务变成铁板一块经常是因为事务处理要求，某个服务方法的代码很多，需要塞在同一个事务边界内，虽然这带来了高一致性的，但是扩展性比较差，因为同一个事务边界内的动作无法分离到几个微服务中，因此，使用微服务必须积极拥抱最终一致性，对分布式系统以及CAP定理有一定理解。当然，这些都是必须有多个微服务调用的情况下才需要考虑，由于微服务粒度小且专一，可以通过组合替代共享继承的思路，容忍代码有一定的重复性。
　　一个微服务架构需要具备以下条件:
<ul>
<li>基础监视 测量和健康检查</li><li>分布式日志 跟踪</li><li>针对每个服务，不只是隔离代码，还需要在构建+测试+打包+提交整个环节隔离。</li><li>能清晰定义每个服务的上下游、编译时间和运行依赖。</li><li>掌握如何构建、暴露和维护好的API和合约。</li><li>需要尊重b/w和f/w兼容性，即使你可能不同时是你生产的服务的消费者。</li><li>好的单元测试和更具有可读性</li><li>注意微服务与模块和库包区别，以及分布式整体型monolith, 协同版本发布，数据库驱动继承的区别。</li><li>知道基础设施的自动化</li><li>需要基于CI/CD持续集成/持续递交的基础设施</li></ul>
　　服务划分：
<ul>
<li>根据业务能力界定服务的范围</li><li>根据领域驱动设计中子域的概念界定服务的范围</li></ul>
　　通讯模式：
<ul>
<li>使用基于RPC的同步通讯方式</li><li>使用异步消息进行服务间通讯</li></ul>
　　 外部API：
<ul>
<li>API 网关（API gateway） - 为每一类客户端提供一个访问服务的独特接口</li><li>服务前端的后端（Backend for front-end） - 为每一类客户端都提供一个独立的 API 网关</li></ul>
　　 数据管理：
<ul>
<li>每个服务都拥有它私有的数据库特接口</li><li>服务之间共享同一个数据库</li><li>使用事件来维护服务间的数据一致性 事件溯源/CQRS</li></ul>
　　 运维监控：
<ul>
<li>服务的发现：通过第三方模块来进行服务实例信息到服务注册表的注册过程</li><li>分布式追踪（Distributed tracing）new - 在服务代码中针对每一个外部访问，都分配一个唯一的服务标识符，并在跨服务访问时传递这个标识符以供追踪分布式引发</li><li>断路器（Circuit Breaker） - 当远端服务返回的故障率超过一定的阀值时，客户端代理（比如 API 网关）对远程服务的调用将立刻返回失败的信息</li></ul>
<hr>
<h2 id="h2-u5FAEu670Du52A1u7406u8BBAu4E0Eu5B9Eu8DF5"><a name="微服务理论与实践" class="reference-link"></a>微服务理论与实践</h2><ul>
<li><a href="http://xmanong.com/ii/4510" title="微服务入门所需了解的一切">微服务入门所需了解的一切</a>
</li><li><a href="http://xmanong.com/ii/4515" title="Docker微容器+微服务将颠覆传统的软件架构">Docker微容器+微服务将颠覆传统的软件架构</a>
</li><li><a href="http://xmanong.com/ii/4516" title="分布式事务可能是个伪概念">分布式事务可能是个伪概念</a>
</li><li><a href="http://xmanong.com/ii/4517" title="微服务架构简介">微服务架构简介</a>
</li><li><a href="http://xmanong.com/ii/4518" title="DDD（领域驱动设计）是微服务体系结构的核心和最重要的基础">DDD（领域驱动设计）是微服务体系结构的核心和最重要的基础</a>
</li><li><a href="http://xmanong.com/ii/4519" title="如何构建基于DDD领域驱动的微服务？">如何构建基于DDD领域驱动的微服务？</a>
</li><li><a href="http://xmanong.com/ii/4520" title="关于有界上下文和微服务的关系以及它们的划分粒度 - Alberto Brandolini">关于有界上下文和微服务的关系以及它们的划分粒度 - Alberto Brandolini</a>
</li><li><a href="http://xmanong.com/ii/4521" title="微服务实现工具概述">微服务实现工具概述</a>
</li><li><a href="http://xmanong.com/ii/4522" title="为什么分布式微服务很难？">为什么分布式微服务很难？</a>
</li><li><a href="http://xmanong.com/ii/4523" title="请放弃RPC！分布式编程第一谎言：网络是可靠的 - David Boike">请放弃RPC！分布式编程第一谎言：网络是可靠的 - David Boike</a>
</li><li><a href="http://xmanong.com/ii/4524" title="如何设计最佳的微服务架构">如何设计最佳的微服务架构</a>
</li><li><a href="http://xmanong.com/ii/edit/4525" title="实现微服务的唯一方法是：在系统全局和本地两个级别平衡每个服务的复杂性">实现微服务的唯一方法是：在系统全局和本地两个级别平衡每个服务的复杂性</a>
</li><li><a href="http://xmanong.com/ii/4526" title="三件事能让你的微服务更具有弹性">三件事能让你的微服务更具有弹性</a>
</li><li><a href="http://xmanong.com/ii/4527" title="为什么微服务应该是事件驱动？">为什么微服务应该是事件驱动？</a>
</li><li><a href="http://xmanong.com/ii/4528" title="使用消息系统集成和扩展微服务">使用消息系统集成和扩展微服务</a>
</li><li><a href="http://xmanong.com/ii/4529" title="Lagom是一个集成ES/CQRS的Reactive微服务框架">Lagom是一个集成ES/CQRS的Reactive微服务框架</a>
</li><li><a href="http://xmanong.com/ii/4530" title="使用Spring Cloud和Reactor在微服务中实现EventSourcing">使用Spring Cloud和Reactor在微服务中实现EventSourcing</a>
</li><li><a href="http://xmanong.com/ii/4532" title="微服务的最终一致性与事件流">微服务的最终一致性与事件流</a>
</li><li><a href="http://xmanong.com/ii/4533" title="什么是Serverless架构？">什么是Serverless架构？</a>
</li><li><a href="http://xmanong.com/ii/4534" title="Spring Cloud微服务架构介绍">Spring Cloud微服务架构介绍</a>
</li><li><a href="http://xmanong.com/ii/4535" title="通过事件风暴和DDD建立微服务时优先考虑">通过事件风暴和DDD建立微服务时优先考虑</a>
</li><li><a href="http://xmanong.com/ii/4536" title="正好一次(Exactly-once)消息传递在Kafka中已经完全支持">正好一次(Exactly-once)消息传递在Kafka中已经完全支持</a>
</li><li><a href="http://xmanong.com/ii/4537" title="如何将单体分解成微服务">如何将单体分解成微服务?</a>
</li><li><a href="http://xmanong.com/ii/4538" title="聊聊微服务的分布式通讯">聊聊微服务的分布式通讯</a>
</li><li><a href="http://xmanong.com/ii/4539" title="业务流程的新实现：微服务和事件编排">业务流程的新实现：微服务和事件编排</a>
</li><li><a href="http://xmanong.com/ii/4540" title="两个领域事件驱动的开源项目介绍">两个领域事件驱动的开源项目介绍</a>
</li><li><a href="http://xmanong.com/ii/4541" title="如何设计实现真正的响应式微服务系统？">如何设计实现真正的响应式微服务系统？</a>
</li><li><a href="http://xmanong.com/ii/4542" title="CAP定理在分布式系统设计中的最新应用">CAP定理在分布式系统设计中的最新应用</a>
</li><li><a href="http://xmanong.com/ii/4543" title="微服务分布式事务Saga模式简介">微服务分布式事务Saga模式简介</a>
</li><li><a href="http://xmanong.com/ii/4544" title="从CRUD编程切换到事件溯源和区块链编程">从CRUD编程切换到事件溯源和区块链编程</a>
</li><li><a href="http://xmanong.com/ii/4545" title="错误的二元论导致单体和微服务的对立">错误的二元论导致单体和微服务的对立</a>
</li><li><a href="http://xmanong.com/ii/4546" title="使用SpringCloud将单体迁移到微服务">使用SpringCloud将单体迁移到微服务</a>
</li><li><a href="http://xmanong.com/ii/4547" title="LMAX微服务级别的分布式事务实现">LMAX微服务级别的分布式事务实现</a>
</li><li><a href="http://xmanong.com/ii/4548" title="从微服务到工作流：Jet订单系统演变过程分享">从微服务到工作流：Jet订单系统演变过程分享</a>
</li><li><a href="http://xmanong.com/ii/4549" title="微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较">微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较</a>
</li><li><a href="http://xmanong.com/ii/4550" title="DDD实践：在SpringBoot中跨微服务通过发件箱模式实现分布式事务机制 - Hans-Peter Grahsl">DDD实践：在SpringBoot中跨微服务通过发件箱模式实现分布式事务机制 - Hans-Peter Grahsl</a>
</li><li><a href="http://xmanong.com/ii/4551" title="切实有效的三个步骤：如何通过划分有界上下文设计微服务？ - Robert Reppel">切实有效的三个步骤：如何通过划分有界上下文设计微服务？ - Robert Reppel</a>
</li><li><a href="http://xmanong.com/ii/4552" title="在分布式事务失败的情况下实现一致性：在线事件处理OLEP(事件溯源)-ACM权威">在分布式事务失败的情况下实现一致性：在线事件处理OLEP(事件溯源)-ACM权威</a>
</li><li><a href="http://xmanong.com/ii/4553" title="不使用DDD的后果：为什么我们停止了向微服务的迁移？">不使用DDD的后果：为什么我们停止了向微服务的迁移？</a>
</li><li><a href="http://xmanong.com/ii/4554" title="Spring Boot实现DDD的货运Cargo微服务案例源码">Spring Boot实现DDD的货运Cargo微服务案例源码</a>
</li><li><a href="http://xmanong.com/ii/4555" title="忘记单体与微服务，重要的是团队的认知能力和范围！">忘记单体与微服务，重要的是团队的认知能力和范围！</a>
</li><li><a href="http://xmanong.com/ii/4556" title="Spring Boot微服务中的十二因子方法论(12Factor) - Baeldung">Spring Boot微服务中的十二因子方法论(12Factor) - Baeldung</a>
</li><li><a href="http://xmanong.com/ii/4557" title="基于微服务框架Micronaut和Eventuate Tram实现分布式事务的开源案例">基于微服务框架Micronaut和Eventuate Tram实现分布式事务的开源案例</a>
</li><li><a href="http://xmanong.com/ii/4558" title="可以促进微服务设计的DDD事件风暴建模技巧 - Nick Tune">可以促进微服务设计的DDD事件风暴建模技巧 - Nick Tune</a>
</li><li><a href="http://xmanong.com/ii/4559" title="向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？">向领域驱动设计前进： 如何使用DDD实现从单体到微服务迁移打造业务平台或中台？</a>
</li><li><a href="http://xmanong.com/ii/4560" title="金融领域微服务架构中如何实现分布式事务？如何记录更多事件，存储在哪里？事件顺序如何保证？ - Revolut">金融领域微服务架构中如何实现分布式事务？如何记录更多事件，存储在哪里？事件顺序如何保证？ - Revolut</a>
</li><li><a href="http://xmanong.com/ii/4561" title="如何微服务在实现分布式事务的变通？">如何微服务在实现分布式事务的变通？</a>
</li></ul>
-<a href="http://xmanong.com/ii/4562" title=" DDD（领域驱动设计）是微服务体系结构的核心和最重要的基础"> DDD（领域驱动设计）是微服务体系结构的核心和最重要的基础</a>。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论