从工作体验切入
开始部署应用
在很久很久以前，开发与部署web应用时，一开始都是很开心地写完‘整个’应用，以包或者文件夹等方式部署到服务器上。在java中，用war包部署到tomcat服务器；在.net中，在IIS管理器中指定文件夹。应用就这样愉快地运行着。
噩梦开始前兆
突然，开发的应用是一个有市场潜力的应用，或者客户想开发2期，3期...... 这样，应用越变越大、项目上线了、修改bug变得越来越吃力、以前开发此功能的同事走了，修改bug用添加代码的方式修改、项目启动越来越慢。
就这样，项目支撑了几年...
噩梦开始前的准备
技术负责人突然发现，项目支撑不了多长时间了。并且有其它项目可用到我们开发的功能组件，例如图片处理功能。
技术负责人很负责地把应用拆分。分成不同的服务开发的形式。例如我们开发的是一个商城平台。技术负责人把商城平台拆分成：图片处理服务、交易服务、用户管理服务、商城数据服务（包括商品、类别等）。这时候，系统开发者们很骄傲地看到此应用拆分成的服务可以跑很多年。
架构的追求
商城拆分的服务跑得很完美，但是随着服务的添加与拆分，架构师看到了重复的工作与服务存在不合理的架构。
什么样的重复工作呢？当添加一个服务时，手动添加VM来部署、前端又要添加请求新域名IP的服务。
并且不合理的架构：1）多个服务使用同一个数据库，可能导致数据库压力过大。2）服务的粒度区分不明显，有大有小。3）服务没有同一的认证中心。4）服务动态修改实例数很麻烦。
针对上面所有的问题，微服务设计思想，就提出了。
微服务开播啦！
什么是微服务？微服务是一种架构设计，集合了多个概念而成。因为微服务要运行在分布式环境，提倡自动化，所以微服务有很多专业的实现名词。包括服务发现、熔断限流、服务网格、API网关等。这些个名词，都会用普通话来开篇叙说。
微服务可以单独跑在一个VM或者Docker上。并且有自己的专门数据库。这个很好理解，微服务提倡解耦。每个微服务可以连接自己的数据库，并且此数据库是独立存在于其它微服务。其它微服务想要访问数据的时候，可以访问我微服务的API即可。
微服务可以编写自己的编程语言。甚至于，在同‘一堆’微服务里，商品微服务用C#、用户微服务用Java、购物车微服务用PHP。多么的‘解耦’啊！
微服务的粒度提倡不要太少。有人说，微服务的粒度控制在10个类以内，每个类100行代码以内。我的天！这个按代码区分的微服务粒度也太低了！反而引起服务的过度调用。如果平时你要下单购买一个商品时的流程，只需要访问订单、商品、支付微服务。但是你区分的太少，可能访问的微服务变成了十几个，甚至上百。这样想一下性能也太低了吧！因为每个微服务运行在单独的进程里。
告诫
在选择使用微服务前，需要考虑团队是否有相应的技术。开发微服务需要的技术人员技术相应较高，并且需要理解微服务的一些基本原理，除非公司已经有了一套完整的微服务框架，开发人员只需要在上面像单体应用地开发。
微服务开发前期需要的周期会相应的增加，甚至是增加几倍。
微服务需要有相应程序的运维团队去运维你的微服务。如果公司有自己的运维一体化工具，则省去了这个建队需求。
所以，在使用微服务前，考虑周到，不要盲目地追求使用。最后你可能项目延期、性能比单体应用还慢！
期待
微服务，还有一段很长的路要走。就在今年2018，微服务提出了2.0版本，服务网格。期待微服务整个体系慢慢完善统一起来。
微服务的好处
1）数据源隔离，达到解耦的目的。每个微服务有自己的数据源，如果需要迁移微服务、加大微服务实例数都非常简单，不用再考虑数据切分的事情了。
2）统一的认证中心、服务发现、服务网关。统一了分布式开发的工具、设计思想。
3）系统越大，相应地开发周期不会线性的增长。
微服务的劣处
1）微服务是分布式开发，所以开发变得异常复杂。分布式系统存在着两大难题，一个是分布式事务，另外一个是分布式锁。
2）微服务粒度越细，性能越低。
3）如果没有自动化部署工具，微服务部署变得一场复杂。
可以关注本人的公众号，多年经验的原创文章共享给大家。
