微服务框架为什么选择Spring Boot作为微服务的入门级微框架

如何使用 java 构建微服务

在Java生态中，构建微服务的策略包括Container-less，Self-contained，以及In-container等。

Container-less微服务将应用及其依赖打包成一个单一的jar文件。

Self-contained微服务也是打包成一个单一的Jar文件，但它还包括一个嵌入式框架，这个框架含有可选的第三方lib，当然这些lib是兼容的。

In-container微服务打包成一个完整的Java EE容器，该服务在Docker镜像中实现。

基于微服务的架构给架构师和开发者带来了新的挑战，然而，随着语言的升级和工具数量的增加，开发者和架构师完全有能力应对这样的挑战。

Java也不例外，本文探讨了在Java生态系统内构建微服务的不同方法。

为什么说要搞定微服务架构，先搞定RPC框架

无论是SOA还是微服务，核心都是RPC框架。

如果没有统一的RPC框架，各个团队就需要实现自己的一套序列化、反序列化、网络框架、连接池，线程池、超时处理等“业务之外”的重复劳动，所以统一RPC框架，是服务化首先要解决的问题。

现阶段，外界RPC框架众多，如果没有特殊需求，并不需要自研一套。

无服务架构和微服务器架构的区别

微服务架构中有两个阵营，一是坚持微服务是无状态的HTTP API服务，另一阵营认为微服务本身就要求把整个系统当做一个完整的分布式应用来对待，而不是原来那种把各种组件堆积在一起，“拼接”系统的做法。

无服务架构就是原来那种把各种组件堆积在一起，拼接系统的做法。

微服务架构 如何影响传统的软件架构设计

ThoughtWorks首席咨询师王磊通过一个互联网门户案例为大家解释了微服务架构的概念，以及它如何影响传统的软件架构设计。

一年前，该门户每签一个10万的合同所耗费的成本是3.5天。

他们当时的CRM结构是典型的三层架构，整个应用程序由一个40万行的代码库组成，后端有一个主动的数据库。

虽然使用三层架构的成本比较小，但随着代码和功能的增加，代码库不断膨胀，修改代码存在的风险很大，整个维护成本也变得越来越高。

每当开发人员提交代码后，所需的数据集成和构建需要50分钟，意味着每天8小时工作时间最多能有9次代码提交。

但为了系统的稳定性，持续集成过程中要尽量避免提交代码，因此，整个团队的交付能力受到了限制。

此外，从准备部署包到上线需要3天，3天后才能让用户真正用到部署包，才能实现价值。

而如果增加新人，要开发新的环境，包括测试和产品环境，培养周期会很长。

针对以上难题，ThoughtWorks制定了如何在团队中对系统进行改造从而满足业务需求的策略。

将现有的系统保护起来，把所有开发新功能的优先级都降下来，只需对系统做最紧急的修改，其他和部门进行协商，让团队保持新的精力和时间在重要的业务上。

功能剥离。

通过定义新服务，在前端用一些代码的机制让用户逐渐访问新服务，可以达到从原有系统抽出小功能，让客户访问小功能。

数据解耦。

对于庞大的系统，因为无法很快将所有系统换掉，所以为了保证系统仍然可用，要启用数据同步机制，让服务里的数据同步到原有数据库。

渐进替换。

通过不断地运行以上策略，将原有系统的复杂功能抽离出来用新的方式来做。

目前，每签一个10万的合同所耗费的成本由3.5天变为1天，持续集成构建从50钟降低到18分钟，团队成员从10人降到7人，部署周期由3天降到2小时。

对于每个应用程序，可能有一组小的服务组成，每个服务运行在自己的进程中，服务与服务之间通过轻量级的机制进行交互。

那么，如何使用微服务做系统改造呢? 为每个服务建立独立的环境，包括基础设施、持续集成环境、运维、监控、日志聚合、报警。

不断演进的微服务开发模板，发现问题及时修改，让模板更高效。

轻量级的通信协议。

消费者的契约测试，解决随着服务增多带来集成测试效率低的问题。

基础设施自管理，帮助管理自己需要的资源。

为什么选择Spring Boot作为微服务的入门级微框架

简单来说，因为上手简单 spring mvc相较于struts清爽太多，但是仍需要配置，这些配置一定程度上提升了入门的难度，需要一定的学习，而spring boot几乎做到了零配置（大量默认配置，当然可以修改的），简单几行代码就可以实现请求响应的过程，一个稍微有点儿Java基础的人，即使没有丝毫的spring知识，上手spring boot，实现简单接口的开发，几天就可以摸清楚，熟悉了之后对后期系统学习spring和spring mvc都有好处（想一想，公司使用spring boot，刚入职的新人毕业生什么的，不到一个礼拜就可以干活。

。

。

。

）