微服务是最近非常热门的技术，关于它的讨论很多。下面从我的实践经验说说我对它的理解。
在我看来微服务就是把很大的应用分成若干个相互独立的小的应用，通过Rest API提供服务或者获取服务。
这样做有很多好处，比如解耦系统、技术选型灵活、易于水平扩展，等等。具体可以参见「Chris Richardson 微服务系列」微服务架构的优势与不足
对于开发来讲，微服务所带来的复杂性和挑战也是很明显的，至少有以下几点。
-
需要实现统一的服务管控和治理平台
比如服务发现，API网关，断路器，分布式配置等等，但好在已经有了开源的解决方案，比如Netflix OSS。
-
如何跨库查询？
A服务的a表需要和B服务的b表做连接查询，如果a表和b表在同一个数据库中是非常简单的，但在微服务中，通常每个服务有自己的私有数据库，每个服务都通过API对外提供服务，那么这时候如何做连接查询呢？我们这时就做不了连接查询了，只能调用Rest API达到目的。
-
如何维护数据一致性？
某个事务需要同时往A服务的a表和B服务的b表插入数据。如何维护数据一致性呢？（当a表插入成功，b表插入失败时数据产生了不一致）
数据一致性有强一致性，也就是分布式事务，以两阶段提交为代表；也有最终一致性（Eventually Consistent），是指不保证在任意时刻数据都是一致的，但在一段时间后，数据会最终达到一致状态。
由于分布式事务会极大的降低系统的并发量，在高并发的系统中一般使用最终一致性。而如何实现最终一致性是个很有挑战的课题，目前没有一种很简单很完美的方案能够应对所有场景。关于这个话题，可以参考分布式系统事务一致性解决方案。
早在1987年，Fred Brooks就曾经说过，“没有银弹”。微服务最近火热，很多人都想去尝试它，但也要看到，实践微服务本身也是具有挑战的，也具有一定复杂性。换句话说，不是所有的公司和所有的业务场景都适合去用微服务架构，单体架构仍然具有自己的生命力。关于使用微服务的前提条件，可以参考微服务概念的提出者软件大师 Martin Fowler 的MicroservicePrerequisites
以下还有一些关于微服务的很好的资料，供大家参考。
