微服务工具箱——前言

什么是微服务

微服务是当前业界非常流行的软件架构风格，它强调将较大的应用按业务逻辑拆分成一个个独立的小应用。这些小应用可以独立地编译及部署，并通过各自暴露的Http Restful API接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地进行扩容。

微服务带来的好处

微服务的好处是大型应用变得更容易管理，在使用微服务架构模式的情况下，软件开发人员可以通过编译并重新部署单个子服务的方式来验证自己的更改，而不再需要重新编译整个应用，从而节省了大量的时间。同时由于每个子服务是独立的，因此各个服务内部可以自行决定最为合适的实现技术，使得这些子服务的开发变得更为容易。最后如果当前系统的容量不够了，那么我们只需要找到成为系统瓶颈的子服务，并扩展该子服务的容量即可。

微服务带来的挑战

但是使用微服务也会带来了很多的挑战，比如：

1. 分布式的复杂性： 大系统被拆分后，各个微服务都是独立部署和运行的，它们只能通过通信来协作，导致之前单体应用的问题都会升级成分布式系统的问题，如： 分布式事务、分布式锁、分布式任务、分布式调用等，而解决分布式问题的技术挑战更大。

2. 排查错误变得困难： 微服务允许各个小系统组成一个大系统，这使得大系统更容易构建，但是一旦某个微服务开发时引入 bug， 排查起来会更困难，复杂的跨进程之间调用，很容易丢失掉重要的出错信息，顺着调用链路排查问题可能会涉及到多个团队的协调，每个团队技术标准不同、立场不同、对整个系统的理解不同，都会使排查问题变得更困难。

3. 部署和测试变得困难： 微服务和传统的单体应用相比，在测试策略上，会有一些不太一样的地方。简单来说，在微服务架构中，测试的层次变得更多，而且对环境的搭建要求更高。比如对单体应用，在一个机器上就可以setup出所有的依赖，但是在微服务场景下，由于依赖的服务往往很多，要搭建一个完整的环境非常困难，这对团队的DevOps的能力也有比较高的要求。

......（还有很多困难，这里不一一列举）。

本书目标

虽然实施微服务有很多困难，而仍然瑕不掩瑜，并且业界有很多公司或个人贡献自己的智慧，提供了很多好的开源项目来解决这样或那样的困难。

terran4j 也根据以往的开发经验，提供了一些开源项目，用于解决其中的某个或某几个问题，这些项目都不大，但针对性非常强，类似于工人师傅的螺丝刀、扳手等工具，看起来小但非常实用。

本书对这些项目进行汇总一一讲解，所以起名为《微服务工具箱》。