AWSomeDay 中体会的Micro Service 微服务

微服务的概念里，有两个重点，快速发布和解耦。这两点都可以和OO中的架构设计原则相对应，一个是单一职责（single responsibility），也就是把一件事情做好，一个是关注分离（Separation of concerns）。康威定律说：设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。对应到这里，也就是说微服务和公司的组织架构有非常紧 密的关系。另外，很多公司都已经是微服务了，只是他们没有提，比如亚马逊、阿里巴巴。像他们这么大的公司，没有微服务根本玩不转。
微服务革新了软件的生产过程，包括开发、测试和部署各个阶段。但服务的切分并不是要遵守单一原则，因为未来的服务不可能完全垂直切分。从另外一个 角度看，微服务的过程其实也是工业化的工程，每个微服务都是生产线上的一个零件，但要注意，零件的组装和拼接难度更大，所以在谈论微服务时一定要注意，它 是需要一个大平台支撑的。
首先微服务并不是指代码本身，它包括从代码开发到部署到运维这一系列的工作流程。其次，谈到服务拆分，需要注意的是服务的 SLA（Service-Level Agreement）是不一样的，拆分时需要考虑到哪些是一级服务，哪些是二级服务。最底层的服务直接决定了上层服务的稳定性。
服务化说白了是组件化的一种形式，所有的组件都来源于重构。流程是从上往下写的，写到一定程度时，就会遇到分离、解耦的问题，然后就是组件化，这时才会出现重构。不要上来就追时髦，服务化没有价值。
如康威定律所说，系统架构和团队的组织架构有直接的关系。但并不是说为了微服务而调整组织架构，一般是考虑到业务的需求才调整团队组织架构。微服 务的团队推荐是7个人左右，这也是Netflix的最佳实践。另外，团队与团队之间不要有太多依赖。中小型的创业公司不推荐使用微服务，因为开销成本很 高，对平台的要求也很高。微服务涉及到你是否能有快速提供环境的能力、文化的改变、快速部署、监控等多方面的能力，当这些条件都具备之后，再考虑是否要微 服务。