Open felix-cao opened 6 years ago
软件架构（software architecture）就是软件的基本结构。合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
本篇主要聊一聊微服务架构（microservices architecture）， 微服务架构是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
技术为业务而生，架构也为业务而出现。随着业务的发展、用户量的增长，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。
有位“大神”——马丁·福勒，给出了微服务特点的描述。大概从以下四个方面来说：
按业务拆分服务，这是“水平拆分”;在技术层面的“前后分离”，属于“垂直拆分”;横纵一起切，就把单一的应用拆分成网状的小块应用，这是微服务中“微”思想的体现。
独立部署与相互隔离，每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，相互隔离的。这点充分体现了“我为人人、人人为我”的设计理念，这是微服务中「服务」思想的体现。
关于轻量 API，服务和服务之间还是有通信交流的，其通信交流方式就是通过轻量的API调用服务。这样做的好处是，服务之间不再需要关心对方的模型，仅通过事先约定好的接口来进行数据流转即可。这是微服务中“解耦”思想的体现。
微服务的指导思想其中一块就是关于组织机构调整的，这还有个专门的定律叫“康威定律”。
我们的解决办法也很有效果，在组织机构没有完全按照微服务的理念重新规划之前，这类需要跨组织协同完成的任务，直接成立临时项目组：相关的部门出人的出人、出资源的出资源，指定/选拔一个能 hold 住的项目经理对整件事情负责。
然后大家惊奇的发现：“部门墙”问题不见了，因为所有事情都是组内事情了，整体的完成情况跟全部项目组成员的业绩都挂钩了，事情推进就非常顺利。在顺利交付之后，项目组解散，各回各家。极大的提升了沟通效率、交付速度，同时使得资源利用率也得到了很大的提升。其实很多时候，大家解决问题的想法和思路，并不是要有了微服务才这样做，而是“不谋而合”，微服务就存在于我们日常工作的点点滴滴之中。
要搞微服务了，有啥建议么?通过我们不断的摸索和总结，要做好微服务，就要做好一定的准备工作。
从五个具体的方面来谈：
业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。
服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。
自动测试，一定要自动化。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。
自动运维，微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。
监控，包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。
软件架构（software architecture）就是软件的基本结构。合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
本篇主要聊一聊微服务架构（microservices architecture）， 微服务架构是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
有位“大神”——马丁·福勒，给出了微服务特点的描述。大概从以下四个方面来说：
按业务拆分服务，这是“水平拆分”;在技术层面的“前后分离”，属于“垂直拆分”;横纵一起切，就把单一的应用拆分成网状的小块应用，这是微服务中“微”思想的体现。
独立部署与相互隔离，每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，相互隔离的。这点充分体现了“我为人人、人人为我”的设计理念，这是微服务中「服务」思想的体现。
关于轻量 API，服务和服务之间还是有通信交流的，其通信交流方式就是通过轻量的API调用服务。这样做的好处是，服务之间不再需要关心对方的模型，仅通过事先约定好的接口来进行数据流转即可。这是微服务中“解耦”思想的体现。
微服务的指导思想其中一块就是关于组织机构调整的，这还有个专门的定律叫“康威定律”。
我们的解决办法也很有效果，在组织机构没有完全按照微服务的理念重新规划之前，这类需要跨组织协同完成的任务，直接成立临时项目组：相关的部门出人的出人、出资源的出资源，指定/选拔一个能 hold 住的项目经理对整件事情负责。
然后大家惊奇的发现：“部门墙”问题不见了，因为所有事情都是组内事情了，整体的完成情况跟全部项目组成员的业绩都挂钩了，事情推进就非常顺利。在顺利交付之后，项目组解散，各回各家。极大的提升了沟通效率、交付速度，同时使得资源利用率也得到了很大的提升。其实很多时候，大家解决问题的想法和思路，并不是要有了微服务才这样做，而是“不谋而合”，微服务就存在于我们日常工作的点点滴滴之中。
要搞微服务了，有啥建议么?通过我们不断的摸索和总结，要做好微服务，就要做好一定的准备工作。
从五个具体的方面来谈：
业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。
服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。
自动测试，一定要自动化。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。
自动运维，微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。
监控，包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。
Reference