标签：分布式系统 开发 压力 感悟 系统管理 相关 业务需求 引入 需求
这两天（4月8号，9号）我有幸参加了极客邦的培训课程-微服务架构的设计和实践，能够面对面倾听58架构师-孙玄的亲身授课，个人也是感到非常的荣幸。两天的时间，来回于广州和深圳，虽然不能说自己的技术有了一个质的提升，但至少也是一次很好的交流体现，这一趟不白走！
身为一个技术小白（虽然个人也有四年的开发经验，但大多的技术只是知其然而不知其所以然，而且接触面太狭隘），此次学习最明显的感受是，如果你只会写软件代码，了解与某种语言相关的语法，框架以及架构包括技术，那你肯定会"死的很惨"。作为软件行业从业者，编码仅仅是整个产品从出生到最终的上线交付中最不举足轻重的一个环节，脱离了任何一环它都没有存在的价值。有句老话说得好，不想当将军的厨子不是好裁缝。每个码农心中或多或少都有一个架构师梦，而最终站在架构师的舞台翩翩起舞的往往只有极少数人，大多数人都可能死在架构的前夕。要想成为架构从业者，仅仅关心自己的一亩三分地，而不是拓展其他板块的蓝图，那你的地里永远都不会生产出金子。
话不多说，进入主题。既然是微服务的架构，我就开始谈谈个人的一些看法与理解。
架构是一个十分吸引人的概念，孙老师有句至理名言：脱离业务场景，空谈架构绝对是耍流氓。微服务架构亦如此，如不能最终满足业务需求，服务于业务，那它就没有存在的意义。与微服务架构相对立的另外一种架构师单体架构（Monoliths）。所谓单体架构，个人觉得可以理解为没有架构（此处的架构不包括软件设计中的一下架构，如J2EE，MVC等），所有的服务功能都是运行在一个进程里，如一个传统的war包部署在web容器，这个时候他就是单体的。微服务架构的核心概念则体现在这个微字，究竟多微才算微，粒度应该如何拆分呢？
首先，微服务并不是银弹，也就是说他不是万能的，并不适用于所有的业务场景。比如，针对简单的系统，业务模块只有三五个，无其他的访问或者数据压力，这个时候杀鸡就没必要用宰牛刀了。微服务对于机器的依赖相对于传统的单体服务架构来说更高一点，毕竟要实现微服务，至少需要引入第三方依赖（如消息队列）。此时，开发成本或硬件成本或多或少都会增加。另外微服务的分布式系统管理也会带来更高的运维成本和测试成本。
对于大型的互联网公司而言，他的业务复杂度是不可估量的。为了解决开发效率低，扩展性差，不高可用行的问题，业务模块之间的分离是必然的选择。不过光是业务模块的分割显然还是不能满足业务的需求，如用户模块，用户的注册，用户的空间等等如果还是在一个进程中实现，仍然会存在服务器压力很大的问题。个人认为，在条件允许且有必要的情况下，粒度最好能够小到不能够再分离的地步。最终拆分的服务，即最终的微服务，都会注册到注册中心。
具体的服务架构组成不过多赘述，要了解微服务的整体架构及应用场景包括如何设计，需要了解的技术面很多。从网关层的设计 到聚合层（即业务逻辑层）的设计，原子层再到数据层（DB或cache）的设计都是门很大的学问。如何实现高可用性，最终一致性也是微服务的最终的实现目标。
大致的技术细节不一一细述了，上面提到的也仅仅是我的个人观点，此文章的重点也不是技术，。两天的培训，如果基础不能扎实，如网络硬件或者常用的软件理解的不够深入的话其实是一件很痛苦的事，这也是我的切身感受，因为等待我学习的东西实在是太多了。
每段风光的背后总会隐藏着不为人知的坚信与痛苦，不逼自己一回，那你永远只会是井底之蛙，永远无法体会风光的感觉。外面的世界确实很精彩，外面的牛人也确实很多。所谓适者生存，不适者淘汰，加快自己的步伐，永远不要驻足而立！
标签：分布式系统 开发 压力 感悟 系统管理 相关 业务需求 引入 需求
原文地址：http://www.cnblogs.com/yangmj/p/6687139.html
