初始微服务（一）

随着互联网技术的快速发展，一些传统的IT系统支撑遇到了愈来愈多的问题：

• 系统的复杂性愈来愈高
• 线上访问压力大，交付速度没法知足业务需求
• 设备采购和维护成本高，测试、部署成本高
• IT运维管理复杂，构建一只全功能团队困难

针对上述问题，传统的单体结构已经再也不适用于复杂度日益渐增的产品，所以一种新的软件架构提供了解决方案——微服务。

什么是微服务

微服务架构是一种架构风格，就如MVC、分层架构通常，它有六个特色：

• 一组小的服务：原来单块架构将全部的业务能力打包在一个单块应用当中的，而微服务主张将这些单块应用拆成一个个小的独立的服务。
• 独立的进程：正如Java应用程序能够部署在Tomcat容器中，容器自己也是一个独立的进程，微服务能够部署在容器中，容器能够部署在物理机上 ，以进程的方式去横向扩展微服务
• 轻量级通讯：主张轻量级协议，如http
• 基于业务能力构建微服务
• 独立部署：微服务拆分后由每一个团队各自维护，能够独立进行开发、演化、部署，各部门之间不须要太多的协调，大大提升的团队的迭代效率。
• 无集中式管理：原来的架构是有独立的架构团队制定标准，统一技术栈、统一存储方式。而微服务架构则主张每一个团队选择其最能解决当前问题的技术栈及存储机制。

用一句话来归纳微服务就是基于有界上下文的（局部状态，每一个团队能够维护本身的数据源，服务演化速度比较快，对服务支持更敏捷），松散耦合（服务之间不能强依赖）的面向服务的架构。

微服务优缺点

架构最重要的职责就是权衡，了解微服务的优缺点才能更好地使用微服务。

优点

• 强模块化边界：组件、类库以服务的方式进行调用，能够直接调用服务，而不须要引入包（程序实体）

• 可独立部署：各团队可单独对服务进行维护部署，不须要涉及其余团队进行协同

• 技术多样性：分散式治理，各团队可根据业务实际状况选择最优技术栈

弊端

• 分布式复杂性：服务之间相互沟通协做实现业务功能，清晰理解整个完整架构的难度上升

• 最终一致性：须要维护不一样数据源的状态同步问题

• 运维复杂性：运维团队须要引入监控、进行容量规划以保证服务的可靠性、稳定性，运维难度上升

• 测试复杂性：各服务分散在各个团队，一个完整的业务功能测试可能须要不少团队联合测试

微服务不是银弹，若是一个单块应用尚且搞不定，更别期望微服务能拯救你。

康威法则与微服务的关系

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

上述这句话的意思是设计系统的组织，其产生的架构设计等价于组织间的沟通结构。所以技术架构和组织架构的关系是强相关的，这也解释了为何单块应用随着系统复杂性愈来愈高变得再也不适用。

在业务初期，开发的系统是简单的单块应用，但随着业务量变大，团队规模变大，单块应用架构和多团队之间产生了不匹配的状况，也就是违反了康威法则。

什么时间段引入微服务

在了解康威法则后，何时是引入微服务架构是最优时间点呢，是越早引入越好吗？

答案固然不是。一般状况下，业务初期开发的系统只是为了验证商业模式，并非很复杂，所以并不推荐一开始使用微服务。

微服务适用性

下面这张图表的横坐标表示生产力，纵坐标表示系统复杂性，很准确地描述了微服务的适用性。

微服务有基础设施要求须要必定的前期投资，而单块应用不须要很大投入就能交付基础功能。

随着业务量变大，团队规模和单块应用的矛盾凸显违反了康威法则，生产力会随着业务复杂性降低，这时候要考虑微服务解决问题的交叉点（这个交叉点意味着单块应用已再也不合适，这个时间点的肯定须要架构师综合权衡）

单块优先

上述这张图表很清楚的展现了架构是经过设计出来和仍是演化出来的两个过程。

在业务初期，架构师还对业务问题的领域模型不清晰，一开始直接采用微服务架构进行服务拆分是冒险的。

而若是一开始就采用单块应用的模式，随着业务的发展，架构师对业务问题领域模型愈来愈清晰，这个时候就能准确地找到系统的瓶颈对功能模块进行合理拆分。

微服务组织架构

康威法则是微服务的组织原理，所以能够说微服务架构本质上是组织架构的重组，那么什么样的组织架构更适合微服务架构？

首先来看看传统企业中是如何组织团队的，下面这个图表为传统职能型的团队架构，横坐标标识业务价值流的交付过程，通常来讲一个业务需求先由产品开始到研发到DBA最后上线运维，纵坐标表示业务能力，在传统的企业当中团队划分方式是严格按照职能的。当有项目的时候，会从各个职能团队进行抽调组成交付团队，等到项目完成后再回归各自的职能团队。这种传统的职能划分团队的方式有两个缺点：

• 沟通协调成本高，价值流从一个团队到另外一个团队传递的过程当中须要进行不少沟通协调工做

• 问题反馈不及时，反馈周期长，研发效率低下，对业务支持慢

在微服务模式下，须要一种新型的组织架构方式——基于微服务的跨职能的组织架构。

每一个业务线的团队组织方式再也不是严格的按职能划分，而是跨职能模式，一个团队包括各职能的专家，团队内部造成闭环，围绕微服务进行开发测试和交付。

而DBA、运维团队则把计算、网络存储等持续交付能力封装成一个平台产品，以API调用的形式提供给不一样业务线快速交付迭代。

who builds it, who run it——也就是说微服务团队是围绕着微服务产品进行组织的，团队内部人员要负责架构设计、开发、评审、测试、部署、运行和支持，整个造成端到端的闭环，快速响应业务需求。

未完待续。。。