2018年7月19日，我的处女作《Spring Cloud微服务-全栈技术与案例解析》开卖了。这是一个值得纪念的日子，也是对自己平时学习的考核。
近几年正是微服务大火的时候，我也算抱了抱大腿，作为一个技术人，必须时刻保持着学习之心，正所谓该出手时就出手。
微服务之所以这么火，无疑是解决了我们实际工作中遇到的很多痛点。比如重复代码多，项目臃肿，启动时间变长了等问题。
今天主要谈谈我对微服务的一些理解以及对待技术的态度。
微服务架构是一种架构概念，你可以用Spring Cloud构建，也可以用Dubbo构建，与语言和框架无关。
我眼中的微服务就是拆分，职责单一化。好比一个公司的发展，最开始的几个人组成的工作室，一个人当3个人用，什么都要做。后来慢慢发展到50个人了，会划分出多个部门，每个部门都有自己专注的业务。后面规模更大了之后，一个部门中都会分成很多个小组。我们可以认为每个小组就一个服务，他们专注于某一块的工作，各个组之间都会有配合。所有小组合起来就是这家公司。
架构也是如此，最开始一个项目，什么功能都往里面加，到后面代码量多，功能复杂，一出问题影响整个系统，相比上面的公司也是一样，如果没有严格的部门划分，职责划分，那很有可能就乱成一锅粥了。我也不是什么专家，说的也不一定对，大家就随便理解下吧。
微服务并没有大家想象中的那么神秘，大公司可以做，小公司同样可以。能不能成功实施微服务，取决于你们的技术负责人和各位自己对待技术的态度。
我其实是一个比较开放的人，不会一直封闭在仅有的一些老技术中，喜欢也愿意尝试着在工作中去使用新的技术框架。
一个好的框架用起来会得心应手，提高开发效率。最重要的是得跟上潮流，技术更新太快，作为一位开发人员，只能不断的去学习才能不被淘汰。
最近有看过一篇文章，叫为什么很多大公司还在用老技术？这种就是公司层面的问题了，重构成本太高。还有一种说法就是脱离业务的技术架构都是耍流氓，确实如此，合适的时机做合适的事情。
上面说的我觉得都没有错，你的领导上面有公司的压力，不会说为了用一些新技术去费很高的成本去做重构这件事情。
但是，站在一位普通开发者的角度考虑，如果一直用老技术，当你换工作的时候就会发现落后了很多。当然你也可以自己努力点，自己学习，面试官会说你没实战经验。不是我想学，而是现实如此。
我还是鼓励大家勇敢的去尝试新的技术，遇到困难不可怕，可怕的是你没解决困难的机会，只有不断踩坑，才能成就优秀的你。
中小型团队玩微服务，不要太多高大上的功能，够用，能够支持业务的发展就行了。就以限流来说，如果你们的产品没多大的访问量，说实话，限流与不限流没什么区别，何必浪费这么多时间来做限流这事情，把时间花在完善产品的功能上不是更好。
当然也不是说限流就不重要了，万一有突发情况，万一业务发展太快，请求量暴增，系统频频被冲垮，这个时候限流就很重要了，我想表达的只是对的时间做对的事，有条件的情况下未雨绸缪必须先做起来。
在实施的过程中，我们可以借鉴一些优秀公司已经成功的案例，结合公司本身的业务设计出符合业务发展的架构，结合公司的技术栈选择合适的框架来构建微服务。
正所谓**‘兵马未动,粮草先行’**，公司未动，自我先行。极客时间最新推出了《从0开始学微服务》专栏，由新浪微博架构师胡忠想老师给大家分享微服务架构过程的经验和感悟。
我仔细看了课程大纲，内容非常全面。总共分为四个模块，每个模块的内容都非常多，知识面广。
- 模块一 主要讲解了微服务基础原理，对微服务进行了深度剖析，让你知道什么是微服务，如何做监控，追踪等知识点。并且会以Dubbo为例，剖析微服务架构的具体实现。
- 模块二 模块二的内容就是完完全全的实战，可以称之为‘微服务最佳实践’。其中包括对注册中心，RPC框架的选型建议。服务端故障，客户端调用失败等处理手段。
- 模块三 讲的是微服务怎么做Docker容器化与DevOps。通过容器化和DevOps简化发布流程，构建弹性伸缩架构。
- 模块四 对微服务的展望，未来的微服务会是什么样子？会带给我们怎样的惊喜。作为下一代微服务架构Service Mesh当仁不让，我也非常期待胡老师眼中的Service Mesh是怎样的。
我自己也买了，学习学习前辈的优秀经验。各位读者朋友如果有兴趣，欢迎长按识别海报的二维码购买，价格还是比较合适的。貌似大家购买了我会有返现金额，有购买的朋友可以告诉我，等返现给我了，我再退回给大家，降低大家的学习成本。
胡老师的个人介绍
胡忠想，微博服务化项目架构师&技术负责人，2012年加入微博工作至今，承担过微博计数器架构升级，春晚和奥运服务保障，以及微博feed业务架构升级等工作。目前，主要专注于服务化方向，工作内容包括：微服务治理，弹性调度以及自动化监控等。
