“微服务的本质是什么呢？就是增强了系统单个服务的独立性，从而在一定程度上解耦整个项目系统，使各个子系统也就是各个微服务可以独立修改，部署，测试。达到整个项目的细粒度并行开发。从而使大型项目更快速迭代交付成为可能。”

1

微服务架构是一系列技术组合，

是一个系统，每一部分都很重要

人们谈到微服务架构一般想到什么呢？spring boot， spring Cloud。其中spring Cloud是一系列技术的组合。比如被dubbo用作注册中心的ZooKeeper。Netflix的Hystrix，主要做熔断功能。还有Eureka，也是应该用做注册中心的。

spring Cloud的出现使得一些中小性公司也可以使用微服务架构来构筑自己的产品架构。虽然ZooKeeper并不适合做注册中心，但是但用户数量少的情况下，ZooKeeper也是能够满足一定的需求的。

因为微服务每个服务是独立开发，部署的，服务之间不互相影响，所以微服务架构也非常适合devOps.比如运用Docker,Jenkins，和GitHub可以实现用脚本来自动部署，发布服务。

一般超大型公司，都会选择自研相关的系统，比如注册中心，服务治理，配置中心等等。因为他们的用户规模是非常巨大的，现有的开源框架很难满足他们的定制化需求，也很难保证在大规模用户下的高可用，高并发。

所以一般超大型公司都会在借鉴相关开源框架的设计思想下改进开源框架或者自研。每一个子系统对整个架构来说都是非常重要。

2

微服务架构的选择需要

综合考虑，并不是万能药

微服务是一个非常好的架构，但绝不是项目一定要采用微服务架构，要根据现有公司的技术栈，开发人员的能力，数量，预算，开发周期，以及具体业务来决定。

并不是所有的项目都适合微服务架构。当微服务被拆分成很多服务子系统后，对几百上千个微服务的运维需要有能力的运维团队才行，要不然，很可能是拆分了，体系建立好了，但是运维能力不行，也会导致运用微服务架构的失败。

对于一般小的项目，单体和水平分层架构也不是不可以的。单体架构可以很快开发，推进，成本少，速度快。对于初创公司来说，不失为一种选择，等到用户规模上来的时候，资金充足，人员充足，再根据业务需要重构也不是不可以的。

当然初创企业如果有相关技术人员，也不是不可以考虑微服务架构，可以搭一个简单的微服务架构，以便后期方便扩展。

3

微服务架构就是

水平拆和垂直拆的结合

微服务其实是业务垂直拆和功能水平拆的结合。可以根据业务需要粗粒度拆，也可以细粒度拆，但其中的平衡要自己把控好。太粗则不能有效解耦，太细则对运维和数据一致性有很多挑战。

其实拆分是一件不容易的事情，而微服务化就一定要涉及到分库分表，分库分表也是头痛的一件事，怎么解决跨库join的问题，还有数据一致性的问题，分布式事务的问题。

虽然有开源数据库中间件Sharding，但具体业务中依然会碰到很多问题。

4

service Mesh 

微服务架构2.0版本

service Mesh在中国叫服务网格架构。service Mesh通过联通sidecar,把基础设施下沉到框架内，因为数据传输协议和通讯协议都和语言无关，从而解决了多语言开发的问题。