从架构的角度看分布式系统

应用程序架构正在从一个大而全的模型逐步发展为一个更加分布式的模型。这个变化的关键动力来源之一是云计算的到来及因此而拥有的不断增长的计算规模。对于一个主要从事构建与管理所谓大而全的软件的企业（包括其人员与工作流程），要想开发新的分布式系统，则不仅需要重新学习一些过时的设计方法，还需要会将一些新的模式应用到其中。作为其中的一部分，我将从架构的角度详细介绍在过渡到分布式应用程序的过程中将会凸显出来的问题。

• 调度（Scheduler）与统筹管理（Orchestration management）：管理成百上千个实例（instances）需要系统能够无缝地把实例或容器（containers）从一个主机统筹与调度到另一个主机。为了能够处理不断增长的运算规模，工作量的安排与统筹是分布式系统强大与否的一个关键部分。在解决这一领域的问题中，Docker Swarm、Kubernetes、Mesos与Marathon等是比较成功代表性产品。
• 服务发现（Service Discovery）与注册（Registration）：随着基于容器的服务启动或关闭，我们需要一种机制去注册或注销服务，以及在一种能够运行时发现服务端点的机制。像Consul、Zookeeper、etcd、Confd与Eureka都是在这方面的领军产品。
• 系统状态管理（System State Management）与集群管理（Cluster management）：随着集群规模的增长，我们需要更好地去管理集群的系统状态。如每一个服务都在干什么？总共有多少个实例？以及这些实例都工作在哪些主机上？它们的负载怎么样？这些都需要去有效地管理。而要有效地管理它们，就需要集群管理系统能够实时地监控系统的状态。像Docker Swarm Agents、Kubernetes Nodes/Masters、Mesos Slaves与Containership等产品是在这方面比较有代表性的产品。
• 数据存储：容器的存储周期是短暂的，这就意味着需要在容器生命周期之外的数据需要在外部进行保存。像Docker Volume Plugin、Flocker、Kubernetes Persistent volumes等产品是在这方面比较成功的领军产品。
• 网络：由于每个容器可能运行在不同的进程中，所以我们不仅需要管理容器，有时还要根据服务间的访问权限进行相应的隔离。因为有可能多个容器运行在同一主机中，所以需要通过在网络上创建安全组（security groups）以实现容器间的隔离。另一方面，一个容器可能还需要发现运行在不同主机上的服务，实现跨主机地访问。此类产品中像Flannel、Weaveworks与Calico是其中的佼佼者。
• 监控、审核与日志：由于数以千计的容器在同时运行，对每一个容器进行监控、审核与日志记录将成为一个严重问题。数据与日志要从每一个容器中取出以以便分析。在这一领域，Loggly、Fluentd、log entries、datadog与ELK stack是比较值得关注的产品。

除了上述问题，当构建一个分布式应用程序时，还需要考虑容器的操作系统与容器的运行时环境。其它诸如程序运行时环境、部署管理、DNS、安全问题、SSO/OAUTH、API网关、断路器（Circuit breakers）、性能与可扩展性等问题依然需要被解决。

在你的分布式开发生涯中，如果有其它没有被提及但你又认为很重要的分布式应用架构问题，也可以把它们分享出来。